thoughtbot / thoughtbot/factory_bot
Rubocop (`Rails/SaveBang`) linters `create(my_dynamic_string.to_sym)` when using with dynamic first param
Nobody has claimed this yet.
- Dominant language
- Ruby
- Stars
- 8.2k
- Forks
- 2.6k
- PR merge metrics
- No merged PRs in 30d
Description
Description
I apologies first if I'm not in the right place to ask/report.
I got the Rubocop Rails/SaveBang error triggered when I want to create FactoryBot object, using a dynamic value as first parameter.
See the Rubocop linter in the following
✅ Using with trait create(document_type, :my_trait)
✅ Using with public_send FactoryBot.public_send(:create, document_type)
❌ Using only the dynamic first param create(document_type)
Is it like Rubocop think I'm working with ActiveRecord object 😅
Thank you very much in advance for your help 🙏🏼
Reproduction Steps
Written script :
let(:instance_set_with_dynamic_class) { create(document_type) }
let(:instance_set_with_symbol) { create(:invoice) }
let(:instance_set_with_dynamic_class_with_trait) { create(document_type, :my_trait) }
let(:instance_set_with_symbol2) { FactoryBot.public_send(:create, document_type) }
Expected behavior
I would like Rubocop to not treat this as an ActiveRecord object (user.create(...) VS FactoryBot create(:user))
And not linter my line.
System configuration
factory_bot version: 6.4.5
rails version: 7.0.8
ruby version: 3.2.2
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the reproduction snippets using FactoryBot's dynamic first argument and the reported Ruby, Rails, and factory_bot versions. Compare the behavior of create(document_type), create(document_type, :my_trait), and FactoryBot.public_send(:create, document_type); done means the dynamic FactoryBot call is not incorrectly treated as an ActiveRecord save while the intended Rails/SaveBang checks remain intact.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rails, ruby
- Domain
- testing, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100