Een ketentest die ik recent tegenkwam: je maakt testdata aan via de API, past die vervolgens aan in applicatie A en controleert het resultaat in applicatie B. Of andersom: aanpassen in B, controleren in A. Simpel, zou je zeggen. Tot je merkt dat "Nederland" in de API "NL" heet, in A "Nederland" is en in B ineens "Netherlands".
Testautomatisering van ketentesten en integratietesten heeft
zo haar eigen problemen. Een van die problemen is de testdataweergave, zeker
als je ketentesten en integratietesten een combinatie zijn van API aanroepen en
GUI gebruik. En dan is er nog die combobox, die het net weer anders doet:
"NL - Netherlands". Jouw integratietest gebruikt al deze varianten, niet
alleen als weergave, maar ook om testdata in te voeren.
Hoe hou je hier orde in? In deze blog deel ik mijn
oplossing.
Stap 1 – Maak een goede opzoekstructuur
De concrete oplossing kan per programmeertaal verschillen,
maar waar dit op neer komt is dat je op basis van een keyvalue andere varianten
op kan zoeken. Van belang is dat je dit deel alleen richt op de data. Laat varianten
die je kan baseren op andere weergavevarianten weg, zoals b.v. in het
bovenstaande voorbeeld de waarde NL – Netherlands. Voor de bovenstaande
situatie zou deze oplossing leiden tot de mogelijkheid om op basis van de
waarde NL te zoeken naar een record of item. Vervolgens kan je uit dat record
of item de Nederlandse of de Engelse naam selecteren.
Stap 2 – Maak conversiefuncties
Wanneer je een bepaalde weergavewaarde kan samenstellen uit andere
waardes kan je het onderhoud beperken door hier een conversiefunctie voor te maken.
Omdat binnen een applicatie vaak voor verschillende soorten gegevens eenzelfde
constructie gebruikt wordt, kunnen deze zelfs generiek, los van de data
ontwikkeld worden. Neem de waarde “NL – Netherlands”. Wanneer een combobox de
combinatie “Code - Naam” heeft, hebben vaak meerdere comboboxes dit. Een functie
die tussen twee woorden een streep toevoegt kan dan ook erg generiek gebruikt
worden.
Stap 3 – Maak gestandaardiseerde functies om de data op te vragen
Als je data de ene keer met een conversiefunctie omgezet
moet worden en de andere keer niet kan je code al vrij snel moeilijk te
begrijpen worden. Dit kan je verhelpen door een kleine extra laag toe te voegen,
waarbij je steeds dezelfde functies gebruikt. Uitgaande van het voorbeeld aan
het begin kan je b.v. de functies GetAPIValue(), GetDutchValue(),
GetEnglishValue(), GetEnglishComboboxValue() maken voor een CountryList object.
Wanneer je vervolgens een CityList krijgt, kan je deze precies dezelfde functies
geven. Binnen deze functies regel je vervolgens het opzoeken van de juiste
waarde of waardes en evt. de conversiefuncties die hiervoor nodig zijn. Mocht
dit wijzigen, dan hoef je het maar op 1 locatie aan te passen.
Voor- en nadelen
Het belangrijkste nadeel is dat deze constructie de code
ingewikkelder maakt. Daarnaast breng je zaken, die je als business rules kan
zien, in je testautomatisering. Dit wordt over het algemeen niet aangeraden.
Maar voor mij wegen de voordelen zwaarder.
- Je controleert binnen je testautomatisering slechts op 1 weergavevorm, waardoor je consistentie veel beter test
- De data wordt slechts op 1 locatie bewaard, waardoor toevoegen, wijzigen en verwijderen van data slechts op 1 locatie hoeft te gebeuren
- Wanneer een weergavevorm wijzigt, hoef je de code slechts op 1 locatie aan te passen
- De testcode zelf wordt juist minder ingewikkeld, doordat dezelfde functienamen steeds terugkomen i.p.v. een grote variatie aan conversie of validatiefuncties.
Deze aanpak is niet de enige oplossing, en ook niet voor
elke situatie de beste keuze. Maar in projecten met veel weergavevarianten
heeft hij mij veel onderhoud bespaard.
.png)
