Testautomatisering met NL, Nederland én Netherlands tegelijk

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.