Wat wij geleerd hebben van de deepdive: hoe beoordeel je een testframework

Welkom!

Op onze laatste deepdive doken we in elkaars testframework. In groepen presenteerde we ons framework, en stelde we vragen en review commentaar op. De afgesproken 20 minuten per framework was duidelijk niet genoeg. Elk framework bleek veel interessanter dan je in 20 minuten kunt laten zien. En alles bij elkaar leverde dit een mooie set aan complimenten, tips en trucs op.

Wat wij geleerd hebben van de deepdive: hoe beoordeel je een testframework

We deden dit aan de hand van een lijst met vragen die je jezelf kunt stellen wanneer je een framework opzet, dan wel wanneer je een framework gaat reviewen. Dit bleek een erg handige lijst met vragen te zijn.

Onderstaand deze vragen, incl. de complimenten/tips en trucs die we daaruit gedestilleerd hebben.

Programmeurs focussen nog wel eens op SOLID. Als je een testframework bouwt, ben je ook aan het programmeren. Wij merkte vooral dat de S van SOLID erg belangrijk is bij een testframework.

Hoe start je je testen?

Draai ze vooral ook vanuit de pipeline.
Draai ze op basis van entiteit / gewijzigde code.
Overweeg het parallel draaien van testen voor tijdswinst.
Zorg dat zo veel mogelijk teamleden de testen kunnen draaien, niet alleen de tester. Maak het team testminded.
Zorg dat je makkelijk enkele testcases kunt draaien voor het ontwikkelen van de testen, bijvoorbeeld door gebruik van tags.

Hoe doe je de foutafhandeling en logging/rapportage?

Log zowel welke testen er goed zijn gegaan, als ook welke er fout zijn gegaan. In chronologische volgorde.
Van de falende testen log je meer informatie.
Indien je voor je test ergens random gegenereerde data gebruikt, log dan ook deze data. In geval van flakey testen kan het zo zijn dat bij de ene random gegenereerde data hij mis gaat, en bij de andere hij goed gaat. Maar als je die data niet logt, kun je dat niet achterhalen.
Log alle gegevens van de testcase zoals URL’s, headers, body en parameters, maar ook response headers en natuurlijk response body.
Indien mogelijk, sla in je rapportage ook de log files op in geval van een falende test. De log files kunnen vaak al veel vertellen over de oorzaak van de falende test.
Log het nummer / de naam van de testcase die faalt.
Log het testdoel van de testcase die faalt.
Log de geteste omgeving.
Log de geteste software versie, van elk component.

Hoe bepaal je welke omgeving (OTAP) je gaat testen?

Zorg voor een command line aanroep waarin je de omgeving meegeeft.
Dan kan dat ook goed vanuit de pipelines op de verschillende omgevingen aangeroepen worden.

Hoe ga je om met Page Objects?

Probeer vooral ook samen te werken met de frontend developer. Indien hij al component testen op orde heeft, zal hij hopelijk al Page Objects gemaakt hebben. En zo niet dan is het handig om deze eenmalig aan te maken, en zowel voor component testen als ook voor systeem testen te gebruiken.

Hoe bepaal je welke testen wel en niet uitgevoerd worden?

Gebruik tags om te bepalen welke testen je wanneer wilt draaien.

Hoe bepaal je of testen in een retry moeten?

Bij voorkeur geen automatische retry, omdat daardoor flakey testen snel geaccepteerd worden.
Indien bijvoorbeeld een element niet beschikbaar is, dan kun je binnen een test wel middels polling checken of na verloop van tijd, of na een refresh bijvoorbeeld, een element wel beschikbaar is.
Hoe zorg je voor hergebruik van je code (common components)
Gebruik bijvoorbeeld een constants file voor constante waardes zoals eventuele wait times.
Common components maken onderhoud makkelijker, dat hoeft nog maar op 1 plek. Echter als het toch niet helemaal common blijkt te zijn, dus in de ene test moet een component net iets anders werken dan in een ander component. Dan krijg je al snel dat je last krijgt van common components. Het is dus zeker niet een must. Kies er een wijze balans in.

Hoe ga je om met file/folderstructuur?

Zorg dat bestanden niet te veel dingen bevatten. Zorgen dat een file 1 functie heeft, “single responsibility”.
Zorg dat een file een duidelijke naam heeft. Wat is het doel van je test?
Maar ook voor folder namen geldt, zorg dat ze 1 doel hebben, en dat de naamgeving daar naar is. (single responsibility).
Gebruik voor classes altijd een zelfstandig naamwoord.

Hoe ga je om met secrets?

Zorg voor een keystore met wachtwoorden die je raadpleegt vanuit je code.
Zorg dat de wachtwoorden voor deze keystore niet in GIT worden opgeslagen, maar dat deze lokaal in een secrets file staan.

Algemeen

Overweeg om het Builder Pattern toe te passen.

Je applicatie wordt regelmatig qua architectuur een afspiegeling van je organisatie. Dat is lang niet altijd goed.
Je testframework wordt regelmatig qua architectuur een afspiegeling van je applicatie. Dat is lang niet altijd goed.
Bedenk vooral waarom je welke testen doet, en richt het framework daar op in. Dus wat is belangrijk om te testen, en op welke manier. Zorg dan dat je framework daarin faciliteert.

Hopelijk heb jij ook wat aan deze bevindingen van ons, en kun je zo je framework net weer wat beter maken.

Wil je de volgende keer graag mee discussiëren en direct wat leren, wees welkom. Volg ons op Meetup en schrijf je in zodra we een nieuwe deepdive organiseren.
Graag tot een volgende keer!

Door: Menno Pot, 15-04-2024