Actually I've just released something for that. It's a way of running from your local environment extremely quickly (spoiler alert we use non-local servers).
You can check it out at https://brisktest.com/ we have a demo running Jest at the moment but I'm recording a rails demo right now.
It is interesting to observe the time that things take in various environments. I worked in ad tech previously with lots of offline big-data jobs. Test completion took a few minutes even fully parallelized. Now I work in HFT and our test suite completes on an M1 Max in 21 s and it's got higher coverage.
The situations aren't really comparable. But it's interesting to see the different baselines.
Once you starts parallelizing, CI time is: setup_time + (test_run_time / workers), so assuming money isn't a problem you can add more workers as you keep adding more tests.
What really matter is how fast you can setup your test workers and how slow individual tests are.
Secondly if you're actually trying to startup 100+ test workers per build and so on there's going to be some time distribution for how long it takes for each worker to startup and that adds a bit more time for all workers to complete. This distribution probably isn't _that_ wide timewise but if you really start to push your test suite runtime down it may pop up. If you're running things in docker sometimes a node doesn't have the image in it's docker cache...
Unsure if CI services like buildkite have really made this that much faster but it seems like they are using a single box with 64 cores.
> We never run all of our application’s tests in local development. It’s not a good use of time and will never be as fast as running them on CI.
WTF this is bad practice. Developers should always get in the habit of running tests locally first. No test should require running in the cloud. And, even more, it's actually rare that CI is more performant than your developers' machines. You should invest in your developers.
> Our whole test suite locally takes around 12 minutes running serially on a MacBook Pro.
That's really really really awful. Most projects' tests, even when they're poorly written, still run in 3 or 4 minutes. My own tests run on the order of single-digit seconds.
> We haven’t put much effort here because it’s not something our engineers ever run.
Well of course not. They can't iterate fast if they're slowed down by tests. That's why tests have to be fast!
> This gave us some speed gains, but we wanted it really fast. Our infrastructure team set us up with some 64 core machines
Holy schnapple if I had 64 core machines, a complete test suite would finish on the order of tens of milliseconds!
I'm glad ya'll have gotten your tests down from 12 minutes to 1 minutes. There's a ton more improving you can do though.
That is an absurd statement to make without context.
I work on a large project with a few thousand very well-written tests, which run in 24 minutes serially on a recent-era laptop, or under a minute in well-parallelized CI environment.
This approach is terrible and causes the poor performance.
There are whole sets of testing "tools" for RoR projects that promote this mechanism of testing - if you're testing an API you need to use an external tool to properly hit that API.
If you're writing unit tests, write unit tests with mocked dependencies.
