Linear versnelt tests: waarom snelle code nog niet klaar is

Sneller code schrijven betekent nog niet dat een wijziging sneller klaarstaat. Het ontwikkelingsteam van Linear beschreef op 21 september hoe het zijn automatische controles heeft versneld. Volgens het bedrijf daalde de wachttijd van ruim zes naar iets meer dan vijf minuten, terwijl de verzameling tests sinds januari bijna vier keer zo groot werd. Dat zijn metingen aan Linears eigen systeem, geen beloofde snelheidswinst voor andere projecten.

Wat gebeurt er nadat je code instuurt?

Een ontwikkelaar kan een wijziging eerst als voorstel indienen: een pull request. Een platform zoals GitHub Actions kan daarna automatisch het programma opbouwen en tests uitvoeren. Zo’n afgesproken reeks heet een workflow. Daarbinnen draaien taken op een runner, een computer die het werk uitvoert. Taken kunnen achter elkaar lopen of tegelijk. Moet de ene taak iets gebruiken wat de andere maakt, dan moet zij wachten. Deze automatische controle hoort bij continuous integration, afgekort CI: regelmatig nieuwe code bij elkaar brengen en controleren.

Wachttijd is iets anders dan computerwerk

Neem twee onafhankelijke taken die elk twee minuten duren. Achter elkaar wacht je vier minuten; tegelijk twee. Samen gebruiken ze in beide gevallen vier computerminuten. Dit is ons vereenvoudigde rekenvoorbeeld, zonder opstarttijd. Korter wachten betekent dus niet automatisch minder rekenwerk.

Waarom helpt tests verdelen niet altijd?

Testprogramma Vitest kan testbestanden over groepen verdelen die tegelijk op meerdere computers draaien. Dat heet sharding. Het verdeelt bestanden, niet afzonderlijke testgevallen. Eén zwaar bestand kan daardoor een groep ophouden terwijl andere groepen al klaar zijn. Meer groepen maken lost zo’n scheve verdeling niet vanzelf op. De totale doorlooptijd hangt daardoor niet alleen af van hoeveel tests er zijn, maar ook van hoe het werk verdeeld is.

Bewaren kan sneller zijn dan opnieuw beginnen

Een testcomputer heeft vaak extra softwarepakketten nodig. Dat zijn bouwstenen waarop het project leunt. GitHub beschrijft hoe een schone testomgeving die afhankelijkheden telkens opnieuw moet downloaden. Een cache bewaart herbruikbare bestanden voor een volgende ronde, zodat niet alles opnieuw hoeft te worden opgehaald of gemaakt. Dat is iets anders dan een archief met de uiteindelijke app of een testrapport. Een cache is een hulpmiddel voor herhaald werk. De taak moet ook zonder die voorraad kunnen draaien, bijvoorbeeld door ontbrekende bestanden opnieuw te downloaden. Linear zag ook de keerzijde: een bewaarde pakketmap terugzetten duurde volgens het team ongeveer 28 seconden, tegenover ongeveer 7,5 seconden voor een beperkte nieuwe installatie. Hergebruik was daar dus trager.

Sneller testen vraagt om dezelfde uitgangssituatie

Vitest geeft testbestanden standaard een eigen omgeving. Dat voorkomt dat achtergebleven instellingen in die omgeving uit het ene bestand het volgende beïnvloeden. Die afzondering opgeven kan tijd besparen, maar vraagt om tests die gedeelde toestand zorgvuldig opruimen. Denk aan een nagebootste klok: een volgende test mag niet ongemerkt dezelfde nepdatum erven. Dit is dus een afweging tussen voorbereidingstijd en onderlinge beïnvloeding.

Wanneer mag een wijziging echt door?

Een groen resultaat kan een toegangseis zijn voordat nieuwe code wordt samengevoegd. GitHub laat teams daarvoor verplichte controles instellen. Ook goedkeuring door een reviewer kan verplicht zijn: iemand die de wijziging beoordeelt. Bij drukke projecten kan ondertussen andere code binnenkomen. Dan zegt een eerdere geslaagde controle nog niet hoe beide wijzigingen samen werken. Een samenvoegwachtrij controleert het voorstel daarom met de nieuwste basis en de wijzigingen die al eerder in de rij staan. Zo wordt wachten deels een gevolg van samenwerken. Deze werkwijze is ook bruikbaar voor een Nederlands of Belgisch schoolproject; het gaat om projectinstellingen, niet om een regionale productintroductie.

Wat bewijst een groen testoverzicht?

Een dekkingsrapport laat zien welke delen van de code tijdens tests zijn uitgevoerd. Vitest kan bijvoorbeeld functies en verschillende routes door een voorwaarde tellen. Dat bewijst niet vanzelf dat de controle ook de juiste uitkomst eist. Onze vergelijking: een rekensom bekijken is iets anders dan het antwoord nakijken. Bovendien toont Vitest standaard alleen bestanden die tijdens de testronde zijn ingeladen. Voor een compleet beeld moeten ook andere bronbestanden worden meegenomen. Een mooi percentage verdient dus uitleg: over welke bestanden en welke routes gaat het? Snellere feedback is nuttig, maar de inhoud van de controles blijft bepalend.