Run a load hook when TestFixtures is included

[andrewn617]

Motivation / Background

This Pull Request has been created as a follow up to #47675. In the example I gave in that PR, I showed that you can define an active_model_test_case load hook and shovel onto the fixture_paths. However, I now realize this won't actually work, because TestFixtures itself is included in ActiveSupport::TestCase from a load hook. Since there is no way to control the order the hooks are run in, the fixture_paths method may be undefined at that the time the hook is run.

Detail

This Pull Request adds an :active_record_fixtures load hook. This load hook is run every time TestFixtures is included. So the fixture paths can be added to from this hook. Eg:

module UserManagement
  class Engine < Rails::Engine

    initializer("user_management.fixture_path") do
      ActiveSupport.on_load(:active_record_fixtures) do
        self.fixture_paths << "#{Rails.root}/user_management/test/fixtures}"
      end
    end
  end
end

Additional information

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one change. Changes that are unrelated should be opened in separate PRs.
• Commit message has a detailed description of what changed and why. If this PR fixes a related issue include it in the commit message. Ex: [Fix #issue-number]
• Tests are added or updated if you fix a bug or add a feature.
• CHANGELOG files are updated for the changed libraries if there is a behavior change or additional feature. Minor bug fixes and documentation changes should not be included.

[rafaelfranca]

We need to document this new hook in engines.md

rails/guides/source/engines.md

Line 1463 in 74554cd

### Available Load Hooks

[andrewn617]

I added it. Though.. the column header is "Class" and TestFixtures is is a mixin.. does it warrant it's own section or explanation?

[andrewn617]

I tried something more descriptive, let me know what you think.

[skipkayhil]

I'm a little late since #47675 was merged already, but would it make sense to utilize Engine#paths for this? It seems like this is a very similar pattern to how other paths get added from engines:

rails/railties/lib/rails/engine.rb

Lines 603 to 615 in f91bd40

	initializer :add_view_paths do
	views = paths["app/views"].existent
	unless views.empty?
	ActiveSupport.on_load(:action_controller) { prepend_view_path(views) if respond_to?(:prepend_view_path) }
	ActiveSupport.on_load(:action_mailer) { prepend_view_path(views) }
	end
	end
	initializer :add_mailer_preview_paths do
	previews = paths["test/mailers/previews"].existent
	unless previews.empty?
	ActiveSupport.on_load(:action_mailer) { self.preview_paths |= previews }
	end

[andrewn617]

@skipkayhil Thanks for pointing this out, I wasn't familiar with this. I don't think we need all the functionality provided by ActionView::PathSet - at least for now. But as a forward looking thing, it might be helpful to get rid of fixture_paths= in and implement prepend_fixture_paths, even if the underlying object is just an array for now. Thoughts @rafaelfranca?

Edit: hmm on second thought, I think we need fixture_paths= no matter what, since apps should have the ability to replace the fixture path whole cloth (as they already can do).

[rafaelfranca]

We will probably end up there with the feature I'm working on, but right now I don't think we need to use engine paths just yet.

[rafaelfranca]

Let's just merge the two and change classes to constants. i18n isn't a class and we put in the same table.

[andrewn617]

Done