shards

How many forks to spread the fixtures over. Two by default.

Gradle divides test work by class, and all the fixtures live under one generated class, so maxParallelForks alone does nothing. With this set, the processor emits that many classes, each taking every Nth fixture at runtime, and the verify and record tasks get a matching maxParallelForks.

Set it to 1 on a small suite. Each fork pays its own JVM start plus Compose and skiko class loading — measured at ~1.9 s, against ~7 ms per capture with sceneReuse on — so a module with a few dozen fixtures pays more for the second fork than it saves, and this repository's own 28-fixture suite is faster with one.

What it is worth is also machine-dependent, which is the honest reason the default is two rather than four: measured on a 748-fixture suite on an 8-core laptop, two forks took a verification from ~52 s to ~25 s and four to ~18 s, while on a 20-core Linux box four forks were slower than one on a synthetic 400-fixture suite. Measure before raising it.

viddikDesignParity ignores it: that task writes one report for the module, and shard 0 measures everything.