Run the test suite as two jobs, and stop the tests paying for installs nothing uses

Problem/Motivation

The test job was the longest job in the pipeline by a wide margin, running at eight to nine minutes, and nothing had measured where its time went.

Two things decide that time. The job runs the suite through run-tests.sh --concurrency 8, which forks one worker per test CLASS, so a class is a serial chain nothing can split. And the runner pod is scheduled with a CPU request of 2, so those eight workers share two cores.

The second is what governed. Taking work out of the suite did not move the job: with the browser tests already cut by a third and the longest class halved, the job still finished in the same time as a branch carrying none of it, on a runner the lint jobs showed to be the same speed. Nothing was holding the job up except the cores it was given.

Proposed resolution

Split the job so the suite stops sharing two cores, and stop the tests paying for work nothing reads.

1. The job runs as two, by test type: the kernel tests, which are about seven tenths of the work, and everything else beside them. Each gets a pod of its own. The types named cover every type run-tests.sh knows, so a test cannot fall between the jobs, and the count of tests across the two has to equal what the one job ran. Two rather than three, because a pod costs about a minute before it runs anything and the functional and unit tests are twenty seconds of work between them.
2. Kernel tests stop installing entity schemas they never touch. Which ones those are was decided by running each class without them rather than by reading it, and the classes that count queries keep everything they declare, because a test that warms a cache and then asserts that nothing more is read may reach a table on one run and not the next.
3. Browser tests stop installing a whole site per test. A class's setUp() body is the fixture its tests depend on; the site install is the only granularity the framework offers, not the isolation they use. So the tests of a class become scenarios of one test, and each is handed that fixture again. RunsEveryScenario keeps what merging would otherwise cost: a scenario's failure is recorded rather than thrown, so the ones after it still run and the test fails once naming every scenario that broke.

Eight to nine minutes, to about three.

What is not reduced

929 test bodies before, 929 after. Every body is unchanged: each became a private method called as a scenario, or stayed a test. The assertion count falls, and every part of the fall is checking that a fixture was built rather than checking the module: parent::setUp() asserts once that the install succeeded, drupalLogin() four times that the sign-in worked, and installEntitySchema() once per table that the table it just made exists. What each class loses reconciles exactly against how many installs it no longer pays for.

Isolation is genuinely weaker, and a scenario can no longer be selected on its own with --filter. Those costs, and two more, are set out in the comment below.

Remaining tasks

• The kernel job is now the longest, so it is where any further gain is. Folding same-shape kernel tests into one table-driven test, running every case and asserting the whole table at once, is the shape that fits: a single comparison still names every case that came out wrong.
• Nine browser classes still install a site per test. Two of them resisted grouping for reasons not yet understood and keep a site each, which is the right answer while that is true.
• Splitting the kernel job further gains nothing until the longest browser class is split across files, since that class alone is most of the other job.

AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code on the merge request. I reviewed and ran the work myself before posting it.)