As of right now the full build takes over an hour to run, and this makes cycling for PRs and quick iterative development very difficult.

Why does test suite performance matter? First of all, testing is a part of a developer's feedback loop (see @searls talk) and, secondly, it is a part of a deployment cycle.

Unit tests for operations: They test all edge cases in a nice, fast unit test environment without any HTTP involved.

Webpacker opens the door to JavaScript unit test runners that can run in a Node.js process instead of a real browser (typically for speed). Jest, for example, executes tests against a "browser-like" environment called jsdom by default.

a technique that enable a test suite to perform as well as using fixtures (or better if you're running just a few tests from the suite) and read as good as you are used to when using factories

It is not customary in Rails to run the full test suite before pushing changes. The railties test suite in particular takes a long time, and takes an especially long time if the source code is mounted in /vagrant as happens in the recommended workflow with the rails-dev-box.As a compromise, test what your code obviously affects, and if the change is not in railties, run the whole test suite of the affected component. If all tests are passing, that's enough to propose your contribution.