Landen kiezen voor testdata wordt meestal behandeld als een klusje dat na het interessante werk komt. Iemand opent een lijst met elk land dat het systeem ooit heeft gekend, vinkt een handvol bekende namen aan en gaat verder. De keuze hardt daarna uit tot een fixture, en die fixture bepaalt stilzwijgend wat de suite wel en niet kan vangen.
Dit artikel bekijkt de beslissing zelf. Het zet drie assen uiteen voor het samenstellen van een set, legt uit waarom een goede set bewust ongemakkelijke vermeldingen nodig heeft in plaats van alleen populaire, en beschrijft hoe je de set onder versiebeheer houdt zodat een resultaat van vorige maand ook vandaag nog iets betekent.
Waarom verdient de landenset een eigen beslissing?
Een enkele fixture bewijst dat één record kan slagen. Een landenset bewijst dat de regels worden toegepast waar ze horen. Dat zijn verschillende beweringen, en alleen de tweede faalt wanneer een regel aan de verkeerde regio is gebonden.
Neem een regel die aanneemt dat een postcode verplicht en numeriek is. Eén record uit een land dat aan die aanname voldoet, vertelt je dat de regel loopt. Over de landen waar de aanname onjuist is, zegt het niets, en de fout komt aan het licht in productie in plaats van in de suite. De set is het instrument dat deze klasse van gaten zichtbaar maakt, en daarom verdient ze dezelfde beoordeling als het schema dat ze uitoefent.
De set is ook de goedkoopste documentatie die een team kan achterlaten. Een collega die de lijst kan lezen, ziet welke conventies de suite beweert te kennen en welke ze stilzwijgend heeft besloten te negeren.
Drie assen: bereikbaarheid, datamoeilijkheid, grenswaarde
De meeste discussies over een landenlijst gaan in werkelijkheid over welke as ertoe doet. Ze afzonderlijk benoemen is het grootste deel van het werk.
| As | De vraag die ze stelt | Wat ze vangt |
|---|---|---|
| Zakelijke bereikbaarheid | Kunnen we dit land daadwerkelijk bedienen? | Betalings-, bezorg-, afwikkelings- en taaltakken die nooit lopen |
| Datamoeilijkheid | Hoe ongemakkelijk zijn de gegevens zelf? | Tekensets, schrijfrichting, veldlengte en aannames bij het parsen |
| Grenswaarde | Wordt een limiet tot het uiterste gedreven? | Afkappen, layoutoverloop en fouten van één eraf of erbij |
Een set die alleen de eerste as volgt, is een lijst van markten. Dat is een redelijk startpunt en een zwakke afronding, want de ongemakkelijke gevallen concentreren zich precies daar waar geen omzet ze rechtvaardigt.
Wat maakt een goede grenswaarde-steekproef?
Een grenswaarde-steekproef verdient haar plek doordat ze voor een specifiek veld het langste, het kleinste of het minst meewerkende geval is. De landnaam die in de smalste kolom moet passen, de deelnaam die op een gedrukt label moet passen, de adresregel die in een vast vak moet passen — geen daarvan is een curiositeit. Het zijn de invoerwaarden die een vaste breedte blootleggen.
De nuttige gewoonte is om elke limiet te koppelen aan de assertie die ze hoort te breken. Als een veld is bemeten op een comfortabel adres en de set bevat een adres dat allesbehalve comfortabel is, dan heeft de vermelding een reden om te bestaan. Als elke vermelding comfortabel kort is, blijft de layout ongetest, ongeacht hoeveel vermeldingen er zijn.
Breedte en diepgang vervangen elkaar niet. Twintig vergelijkbare landen doorlopen twintig keer hetzelfde codepad; drie goed gekozen uitersten doorlopen drie verschillende.
Hoe ga je om met landen waar een veld niet van toepassing is?
Sommige landen hebben helemaal geen postcodesysteem, en sommige hebben geen bestuursniveau dat aansluit op het veld waar een formulier op staat. Dat zijn geen ontbrekende gegevens. Het is de vorm van de gegevens, en een set die ze weglaat, levert een suite op die een correct adres als ongeldig behandelt.
Het onderscheid dat de moeite waard is om vast te houden, is dat tussen een waarde die ontbreekt omdat het veld niet van toepassing is en een waarde die ontbreekt omdat niemand haar heeft aangeleverd. Alleen het tweede is een defect. Wanneer een formulier zo’n veld overal verplicht stelt, is de landenset het enige dat dit blootlegt: het falende geval kan niet eens worden geschreven zonder een land waarin het veld werkelijk niet bestaat.
Waar een ander artikel de landsspecifieke vorm van een veld al behandelt, blijft dit artikel smal en verwijst het de lezer door. De gids over postcodeformaten per land is de juiste bestemming voor hoe een code eruitziet; de vraag hier is alleen of de set een vermelding bevat waarvoor die vraag betekenisloos is.
Waaruit bestaat een standaardset meestal?
Een set die het contact met een echt team overleeft, komt meestal tot rust in drie groepen, en elke groep doet werk dat de andere niet kunnen.
- Het thuisland, of de plek waar de meeste aannames van het team zijn ontstaan. Het is de basislijn waartegen al het andere vreemd lijkt.
- De belangrijkste markten, gekozen om de takken die ze uitoefenen: bezorging, betaling, afwikkeling en content.
- Een klein aantal uitersten, gekozen omdat ze een limiet breken en niet omdat er iemand naartoe verzendt.
De derde groep is degene die sneuvelt wanneer een suite voor snelheid wordt ingekort, en het is degene die als laatste zou moeten worden geschrapt. Een suite die snel loopt en elk afkapdefect mist, is niet snel, maar blind.
Voor ontwikkelaars: behandel de set als een geversioneerd bezit
De praktische aanbeveling is om de landenlijst niet langer als configuratie te behandelen en haar te gaan behandelen als een bezit met een eigen identiteit.
Geef de set een naam en een versie, en bewaar die identificatie naast de fixtures die ervan afhangen. Wanneer de set verandert, verandert ook de betekenis van elke assertie die ertegen is geschreven, en zonder identificatie is er geen manier om een regressie van een herdefinitie te onderscheiden. Een opgeslagen resultaat is alleen interpreteerbaar als je de set kunt terughalen waartegen het liep.
Bewaar de redenatie in de repository naast de lijst. Noteer voor elke vermelding voor welke as ze is gekozen en welke assertie ze hoort te ondersteunen, zodat de volgende persoon die de lijst uitdunt, weet wat die verwijdert.
Vul de set met geconstrueerde waarden. Fixtures horen nooit de gegevens van een echt persoon te dragen, en een set die uit live records is samengesteld is zowel een privacyprobleem als een reproduceerbaarheidsprobleem. De landen- en regiorgids is een goede plek om te bekijken hoe elk land en elke regio wordt beschreven voordat je een vermelding vastlegt, en een enkele landpagina zoals de vermelding voor de Verenigde Staten laat zien hoe de notities van één land eruitzien wanneer ze op één plek bij elkaar worden gehouden.
Eén voorbehoud dekt alles hierboven. De landenlijsten, regionamen en voorbeeldwaarden die in dit artikel worden gebruikt, zijn synthetische voorbeelden die zijn gemaakt om een beslissing bij het testen van software te illustreren. Ze beschrijven geen echte organisatie, geen echte dataset en geen echt persoon, en ze zijn niet geschikt als bewijs voor iets buiten een testomgeving.
Volgende stappen
Neem de fixtureset die je vandaag gebruikt en markeer elke vermelding met de as waarvoor ze is gekozen. Vermeldingen die bij geen enkele as passen, zijn kandidaten voor verwijdering, en assen zonder vermelding zijn de gaten die eerst moeten worden gevuld. Schrijf vervolgens voor elke vermelding op welke assertie ze beschermt. De gids over dekking van landendata maakt van die lijst iets auditabels, en de gids over de actualiteit van landendata behandelt wat er gebeurt wanneer een vermelding niet meer accuraat is.