In another comment, it said Gitlab moved off ActiveRecord.
The fundamental problem with rspec + ActiveRecord is for each test: you create db state (tons of inserts), run the test (more db reads and writes), and then tear down the state. This is very expensive when you have 100,000s of tests each taking 500ms.
Rails/rspec does not make it easy to stub db state with ActiveRecord.
Does this mean if you only want to run the tests for `users_controller` during development, you still have to load the fixtures for all other tests with each run?
In the normal case. When you start a test it loads from fixtures into its own database.
Any test can make use of what is in that database. So you tend to put a bunch of stuff that is useful for most tests.
If a specific test needs an unusual setup, then it can do whatever is needed to load data. Generate data, load extra fixtures, etc. You can do this on a per test basis, or a group of tests, etc.
An option is to reload everything between each test. Not recommended.
Normal usage is to rollback any changes a test did, so that each test has a clean slate. This tends to be plenty fast. Parallelism can usually be done.
If speed is still a concern, you can get fancy and load up multiple databases with fixtures and divide tests between them. Maybe have 2-8 sets of tests running at same time.
It's been a few years, but I've inherited test suites that take 14 hours and been able to get them down to a few minutes with above techniques.
Something like Guard can be setup to automatically run tests relevant to what you're working on. So you don't have to run full suite each time.
The fundamental problem with rspec + ActiveRecord is for each test: you create db state (tons of inserts), run the test (more db reads and writes), and then tear down the state. This is very expensive when you have 100,000s of tests each taking 500ms.
Rails/rspec does not make it easy to stub db state with ActiveRecord.