Har fået testsuiten ned på 8,9 sekunder

Situation. Testsuiten havde en tidsgrænse på tres sekunder, og seks test lå over den. En testsuite, der tager over et minut, holder op med at blive kørt før hver ændring, og en suite, der ikke køres før hver ændring, er en rapport om fortiden. Instinktet i den situation er at hæve grænsen, og det er sådan, en suite ender på ti minutter.

Opgave. Tiden skulle findes og ikke bare budgetteres ind, hvilket betød at profilere suiten i stedet for at ræsonnere om, hvilke test der så dyre ud.

Handling. Profilen blev taget på hovedtråden, mens suiten kørte, og resultatet modsagde gættet. Hovedtråden sad inde i to kald i 3.989 stikprøver ud af 4.017 — så de langsomme test var ikke dem, der udførte mest arbejde, og næsten hver eneste test kom gennem de samme to steder. Det første var en fast ventetid, der skulle lade asynkront arbejde falde til ro før efterprøvningen — reelt en sleep, betalt af hver test, der rørte hændelsesvejen, uanset om arbejdet allerede var færdigt. Den blev erstattet af en ventetid på den faktiske betingelse med en timeout, så en test, der er klar på fem millisekunder, tager fem millisekunder, og kun en test, der reelt sidder fast, betaler den fulde ventetid. Det andet var opsætning pr. test, der genopbyggede en dyr fixture hver gang, selvom fixturen var skrivebeskyttet og kunne bygges én gang for suiten. Ingen af dem lå i en test, nogen ville have udpeget som langsom; begge lå i den fælles vej, hvilket er grunden til, at hele suiten var ensartet langsom og ikke bare havde nogle få afvigere.

Resultat. Suiten gik fra seks test over tres sekunder — 74 sekunders vægurstid — til 135 test bestået på 8,9, hvilket bringer den inden for det vindue, hvor den kører, hver gang en fil gemmes. Forbeholdet er, at den fælles skrivebeskyttede fixture nu er et koblingspunkt — en test, der ændrer den, vil frembringe en fejl i en anden test, og suitens hastighed afhænger af en disciplin, oversætteren ikke håndhæver.