Splitting a suite across machines is the usual fix for a slow pipeline, and it works until the shard lists drift. Someone adds forty slow integration tests to shard two, shard two becomes the one everybody waits for, and a person ends up owning a spreadsheet of test files.
Splitting by time, not by count
Bellwether already knows how long every test took on its last twenty runs. When it
writes the selection it splits it across however many machines you asked for, so
that each shard carries about the same total duration. Pass --shard 3/8 on
machine three and it reads its own share.
Selection first, then balance
The balancing happens after selection, which is the order that matters. A four-way split of the whole suite still makes every machine run tests the change cannot reach. A four-way split of the selected tests finishes in a fraction of the time and bills a fraction of the minutes.
When a shard is slow anyway
If one shard runs more than twice as long as the median, the run summary names the test that caused it and the time it took against its recorded average. That is usually a test waiting on a network call or a lock, and it is worth a look whether or not you use Bellwether.
