Changing the process of name selection for factory defining
Example:
rails g model UserMedia filename:string --force-plural
...
invoke factory_bot
create spec/factories/user_media.rb
it generates the correct factory naming:
FactoryBot.define do
factory :user_media do
filename { "MyString" }
end
end
Fixes: #356
Closes#231
When generating factories for namespaced models
(like `Admin::User`), we can follow the pattern used by the model and
model test generators of generating the file inside a directory matching
the namespace. With this commit we generate
`test/factories/admin/user.rb` instead of
`test/factories/admin_user.rb`.
PR #135 introduced the ability to generate factories in one file, but it
also removed the ability to use custom templates for generating
factories. This PR adds back the ability to use custom templates when
generating factories in separate files. I doubt this was a heavily used
feature, but it has come up a few times and it I think supporting it
simplifies the generator.
Closes#147Closes#148Closes#193
PR #193 basically reverted #135, which is undesirable. thoughtbot
projects generally prefer putting all the factories in one file.
Co-authored-by: Nick Sanford <me@nicksanford.io>
Fixes#305
When generating factories in the same file (for example
spec/factories.rb), before this PR we didn't put newlines between the
factories. So if you generated a user factory, then a robot factory, you
would end up with something like this:
```rb
FactoryBot.define do
factory :robot do
name { "MyString" }
end
factory :user do
name { "MyString" }
end
end
```
With this PR, generating those factories will now look like:
```rb
FactoryBot.define do
factory :robot do
name { "MyString" }
end
factory :user do
name { "MyString" }
end
end
```
Note that the final newline is not ideal, but it will only be added when
generating the first factory, whereas the missing newline after
factories was happening every time we generated a new factory. So
with this PR we will only need to fix a whitespace style error once,
rather than N-1 times. We can could open another issue to fix the extra
newline at the end, but I think it may be more complicated than it
sounds.
Co-authored-by: Nick Sanford <me@nicksanford.io>
* Address todos generated by rubocop for files in the lib/generators directory.
This partially addresses #293. Since rubocop generated quite a few todos, the commits addressing them are split up into a few different PRs that cover different files.
* Fix underscore seperator in model_generator.rb, and change memoized instance variable name to @_source_root in lib/generators/factory_bot.rb
* get rid of memoized _source_root variable
* get rid of extraneous rubocop rules
Configuration#generators was deprecated in favor of
Configuration#app_generators back in Rails 3.1
(04cbabb0a0).
Since we started work on factory_bot_rails 5, which only supports Rails
4.2+, we no longer need the conditional.
I also updated the development Gemfile, since it was out of date,
and replaced a nested if/else with elsif.
Closes#236
This commit uses ActiveSupport's FileUpdateChecker to allow reloading
FactoryBot of definitions whenever a file in
`FactoryBot.definition_file_paths` gets updated.
This is similar to reloading for
[I18n](ced104d579/activesupport/lib/active_support/i18n_railtie.rb (L60-L70))
and [react rails](83b6175460/lib/react/rails/railtie.rb (L35-L41))
This allows us to get rid of any Spring-specific logic in the railtie,
since [Spring hooks into the application
reloader](0c711ff10b/lib/spring/application.rb (L161)).
This partly solves #211, since we no longer call `FactoryBot.reload` at
all in `after_initialize`. Instead, we will only call it when one of the
files in `definition_file_paths` gets updated. I say it partly
solves #211 because once a definition file gets updated, reloading
would still give warnings about redefining any constants in the
definition files. I wonder how common it is to define constants in the
same file as factory definitions. It's probably better to keep constants
in the autoload path, allowing Rails to handle unloading and reloading
them in development. I would want to see some specific examples before
worrying too much about it.
I would also like to offer a better way to configure the definition file
paths (see #165 and #166) and possibly an option to opt out of loading
definitions at all (could help with issues like #192).
A couple of quirks here:
* the to_prepare block could potentially get
[called multiple times](https://github.com/rails/rails/issues/28108).
It shouldn't matter, since `execute_if_updated` is a no-op if no
updates have been made.
* I noticed that the first time I call `reload!` in the console the
factory definitions get reloaded even when I made no updates to the
definition files. I think it is related to
[this](f7c5a8ce26/activesupport/lib/active_support/evented_file_update_checker.rb (L18)). After the first call
`reload!` works as expected, only reloading the factory definitions
if the definition files were updated.
* Rails uses execute rather than execute_if_updated for the
[route
reloader](https://github.com/rails/rails/blob/master/railties/lib/rails/application/finisher.rb#L133)
and for the [watchable file
reloader](https://github.com/rails/rails/blob/master/railties/lib/rails/application/finisher.rb#L173).
This means that changes to factory definitions will cause reloading of
the whole application. I think this is fine.
This resolves an issue where factory_girl_rails won't get required if
you only have factory_girl_rails declared in the :test group of a Rails
app.
Closes#89
The factory name for the model Namespaced::User wil be :namespaced_user.
The :class option is specified as a string to prevent class reloading issues.
Addresses GH-44
