fredag den 3. november 2017

Just-in-time mocks vs. TDM og planlagte testdata

Når man laver unit test og unit-integrations test er det super smart at lave en form for just-in-time mocks. Årsagen er at denne form for test er sædvanligvis afviklet super hurtigt og er derfor ret ofte enkelttrådet.

Men lige netop det med tråde er et ret stort problem længere oppe i testniveauerne. Det er nemlig sådan at den eneste rigtige indgriben man kan gøre i en Cucumber test som kører i lang tid er at parallelisere den. Det er imidlertid umuligt hvis man benytter sig af just-in-time mocks der jo vil ændre omgivelserne for hele miljøet og derfor alle de tests der bliver afviklet i paralel.

Hvad gør man så?

Jo ser du, det bedste man kan gøre, både for unit test og for systemtest op til integrationstest, er at lave et sæt testdata som modsvarer det som man har i sine testintegrationsmiljøer. Hvis man kan fremskaffe et sådan datasæt vil det betyder at man kan designe sin test ud fra samme regler uanset om det er en ultra mock’et test i unit eller unit integration, om det er en almindeligt mocket test i systemetest, eller om det er en test helt uden mocks i systemintegrations testen. Dette vil gøre testen meget mere transparant i det man kun behøver at overskue et enkelt datasæt samt vil sikre sig at man har den mest afviklingsstabile test muligt.

Der vil formentligt være situationer hvor testdata ikke giver mulighed for at testen kan afvikles transparant på alle miljøer, og i det tilfælder kan man f.eks bruge en tagging funktionalitet som den Cucumber f.eks har til at blænde de test af der ikke kan afvikles på et givent testniveau. Her er det min erfaring at man skal vedligeholde negativ listen, og gå ud fra at alle ellers kan afvikles på alle miljøer.

Dette understreger at deciplinen TDM (Test Data Management) bestemt ikke er død, men desværre bliver den ret ofte nedprioriteret eller direkte syltet indtil at det står så slemt til at man bliver nødt til at gøre noget ved det. Jeg vil derfor anbefale at man hurtigst muligt får styr på sit testdata og efterfølgende holder det under kontrol. Når man så tilføjer integrationer til sit projekt bliver man så nødt til at finde ud af hvad der ligger i de integrationer i virkeligheden og oprette mocks og testdata med det samme, ikke først når man skal lave have sprintdemo om to timer ;-)

Ingen kommentarer:

Send en kommentar