What Do Contribution Guidelines Say About Software Testing?

Stel je open-source softwareprojecten voor als enorme, bruisende gemeenschappelijke keukens. Iedereen kan binnenlopen, een mes oppakken en beginnen met het snijden van groenten (code schrijven) om te helpen bij het bereiden van een beter maaltijd. Maar om de keuken soepel te laten draaien, laten de chef-koks (project maintainers) een Regelboek op het aanrecht liggen. Dit Regelboek vertelt nieuwe helpers hoe ze hun handen moeten wassen, waar ze de ingrediënten kunnen vinden en hoe ze hun gesneden groenten kunnen inleveren zonder de soep te verpesten.

Dit artikel is als een team van onderzoekers dat naar 200 van deze beroemde gemeenschappelijke keukens is gegaan (specifiek die gebruikmaken van de talen Python en JavaScript) om de Regelboeken te lezen en te zien wat ze daadwerkelijk zeggen over testen.

In de wereld van koken is "testen" als het proeven van het gerecht voordat het wordt geserveerd, om er zeker van te zijn dat het niet naar zeep smaakt. De onderzoekers wilden weten: Leren de Regelboeken nieuwe helpers eigenlijk hoe ze het eten moeten proeven, of gaan ze er simpelweg vanuit dat iedereen al weet hoe dat moet?

Hier is wat ze vonden, eenvoudig uitgelegd:

1. De meeste keukens hebben een "Proefsectie" (maar niet allemaal)

De onderzoekers ontdekten dat 78% van de keukens een specifieke sectie in hun Regelboek heeft die gewijd is aan proeven (testen).

• Waar is het? Meestal (58%) staat het in een bestand dat letterlijk "CONTRIBUTING" heet (de hoofdinstructiehandleiding). Soms staat het in een aparte, chique brochure (externe documentatie), en zelden staat het gewoon op het menu (README).
• De kloof: Ongeveer 22% van de keukens had helemaal geen instructies over proeven. Als je in die keukens zou binnenlopen, zou je moeten raden hoe je moet controleren of je eten wel goed is.

2. De "Hoe-te" onbalans: Draaien versus Schrijven

Wanneer de Regelboeken wél over proeven praatten, waren ze erg goed in één ding, maar slecht in iets anders.

• Het "Hoe te draaien" (83,5%): De meeste Regelboeken zeiden duidelijk: "Hier is de magische spreuk (opdracht) om de hele pot te proeven." Het is alsoig zeggen: "Druk op deze knop om de smaak te controleren."
• Het "Hoe te schrijven" (37%): Veel minder Regelboeken legden uit hoe je daadwerkelijk een nieuwe smaaktest maakt. Het is alsof je zegt: "Druk op de knop," maar je leert de helper niet hoe hij een nieuwe lepel moet maken of hoe hij moet herkennen wat een "slechte" smaak is.
• Het resultaat: Helpers weten hoe ze het bestaande eten moeten controleren, maar worden vaak aan hun lot overgelaten als het gaat om het creëren van hun eigen tests voor de nieuwe ingrediënten die ze hebben toegevoegd.

3. Het "Testpiramide"-probleem

In software zijn er verschillende niveaus van testen, vergelijkbaar met verschillende soorten proeverijen:

• Unit Tests (71%): Dit is als het proeven van een enkel ingrediënt (bijv. "Smaakt deze wortel wel zoet?"). De Regelboeken spraken hier veel over.
• Integration Tests (20,5%): Dit is als het proeven van hoe de wortel en de ui samenwerken in de pot. De Regelboeken noemden dit zelden.
• End-to-End Tests (15,5%): Dit is als het proeven van de volledig bereide maaltijd om te zien of het hele gerecht wel werkt. De Regelboeken spraken hier bijna nooit over.

De metafoor: De chefs maken zich veel zorgen over of de wortels wel goed smaken, maar ze vertellen de helpers zelden hoe ze moeten controleren of de hele stoofpot niet gaat aanbranden of dat de smaken wel goed mengen.

4. De ontbrekende "Geheime Wapens"

De onderzoekers keken ook naar geavanceerde kooktips die het testen makkelijker en betrouwbaarder maken:

• Mocking (9,5%): Soms kun je niet het echte zeewater in je soep proeven; je moet dan een nep zoutvaatje gebruiken om het te simuleren. Dit wordt "mocking" genoemd. Slechts 1 op de 10 keukens had instructies over het gebruik van deze nepprogramma's/tools.
• Coverage (25,5%): Dit is een scorekaart die laat zien hoeveel van het recept daadwerkelijk is geproefd. Slechts ongeveer een kwart van de keukens vertelde helpers welke score ze moesten nastreven.
• Best Practices (9%): Algemene tips zoals "Proef altijd voordat je serveert" waren zeer zeldzaam.

De Kern van het Verhaal

Het artikel concludeert dat hoewel de meeste open-source projecten willen dat hun helpers hun werk testen, de instructies die ze achterlaten ongebalanceerd zijn.

Ze zijn erg goed in zeggen: "Hier is hoe je de test draait," maar ze zijn vaak stil over:

• Hoe je een nieuwe test schrijft.
• Hoe je complexe interacties test (integratie).
• Hoe je het hele systeem test (end-to-end).
• Hoe je geavanceerde tools gebruikt (mocking) of kwaliteitsdoelen stelt (coverage).

De les: Als je een nieuwe helper bent in een van deze keukens, weet je misschien hoe je op de "proef"-knop moet drukken, maar je wordt vaak aan je lot overgelaten om zelf uit te zoeken hoe je een smaaktest maakt voor je nieuwe recept, of hoe je ervoor zorgt dat je nieuwe gerecht niet de hele maaltijd verpest. De auteurs suggereren dat projectleiders duidelijkere, completere instructies moeten schrijven, zodat helpers niet hoeven te gokken.