3 commits

Author	SHA1	Message	Date
Daniel Colson	5c52981fcc	Update rails versions on Travis (#367) ... This commit gets the Travis build passing by: - Removing Rails 4.2 so we don't have to deal with bundler < 2 anymore - Bumping to latest Rails versions - Explicitly listing all gems that appear in the default Rails Gemfile - Avoiding bootsnap and javascript, since they aren't relevant to these tests Co-authored-by: alex <alexandr1golubenko@gmail.com>	2020-03-29 11:51:41 -04:00
Daniel Colson	1e55d45bfb	Ensure factory_bot only loads after initialization ... Fixes #336 Alternate solution to #343 The initialization process looks like this: Rails runs all of the initializers 1. Run the ["factory_bot.set_factory_paths"][set_factory_paths] initializer 2. Run the ["factory_bot.register_reloader"][register_reloader] initializer, which sets up a [prepare callback][] 3. Run the [`:run_prepare_callbacks`][] initializer 4. This triggers the factory_bot [prepare callback][], which causes factory\_bot to [reload][] Rails runs `after_initialize` callbacks 1. [I18n initializes] 2. factory\_bot [reloads again][] as described in #334 The double reloading of factory_bot in this initialization is not ideal, but also shouldn't generally cause any problems on its own. The problems people are having in #336 come from the fact that I18n gets set up in an `after_initialize` callback, but factory_bot gets reloaded before the `after_initialize` callbacks are triggered. If the `FactoryBot.define` block references any code that uses I18n translations as it loads, that code will raise an error (references inside other factory_bot methods, or code that uses I18n translations inside of methods still works fine, since the whole Rails initialization process would be complete by the time any of that code runs). This commit changes step 4 above to avoid reloading factory_bot before the application has initialized. [set_factory_paths]: 3815aae2b9/lib/factory_bot_rails/railtie.rb (L17-L19) [register_reloader]: 3815aae2b9/lib/factory_bot_rails/railtie.rb (L21-L23) [prepare callback]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L34-L36 [`:run_prepare_callbacks`]: https://github.com/rails/rails/blob/5-2-stable/railties/lib/rails/application/finisher.rb#L62-L64 [reload]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/reloader.rb#L24-L26 [I18n initializes]: 13e2102517/activesupport/lib/active_support/i18n_railtie.rb (L16-L20) [reloads again]: https://github.com/thoughtbot/factory_bot_rails/blob/master/lib/factory_bot_rails/railtie.rb#L25-L27 Co-authored-by: Danny Garcia <dannygarcia.me@gmail.com>	2019-10-02 18:37:42 -04:00
Daniel Colson	0b24977c34	Write a failing test for reloading with Spring (#330) ... * Write a failing test for reloading with Spring This test captures what I think is going on in https://github.com/thoughtbot/factory_bot_rails/issues/323 Currently the factory_bot_rails reloader only reloads factory definitions when the definition files have changes (using `execute_if_updated`). This can cause problems when editing an application file without also editing a factory_bot definition file. Rails will reload the entire application, but will not reload the definitions. This causes factory_bot to have references to classes that were unloaded from the Rails application and replaced with new classes. https://github.com/thoughtbot/factory_bot_rails/pull/329 replaces `execute_if_updated` with `execute` so that factory_bot_rails will reload the definition files whenever anything in the application is changed. Hopefully that PR will get this test to pass!	2019-04-05 13:32:17 -04:00