Det finns flera anledningar till att skriva automatiserade tester, och att skriva dem kan verka relativt enkelt. Men att skriva "bra" automatiserade tester är betydligt svårare och kräver erfarenhet och träning.
I detta inlägg har jag samlat några övergripande mål som behöver uppfyllas för att automatiserade tester ska bli bra. Målen definieras i tolv egenskaper, och när dessa uppfylls kan vi definiera testerna som "bra".
Här är några övergripande mål som kan vara relevanta:
Tester ska hjälpa oss att förbättra kvaliteten.
Tester ska hjälpa oss att förstå systemet.
Tester ska minska (inte öka) risken.
Tester ska vara enkla att köra.
Tester ska vara enkla att skriva och underhålla.
Tester ska kräva minimalt underhåll när systemet utvecklas.
Om du använder TDD (testdriven utveckling) eller BDD (beteendedriven utveckling), ger testerna dig ett sätt att fånga vad systemet ska göra innan du börjar bygga det. Att gå igenom olika scenarier för att omvandla dem till tester hjälper oss att identifiera områden där kraven är tvetydiga eller motsägelsefulla. En sådan analys klargör målen för specifikationen, vilket leder till en mer korrekt design och förbättrad mjukvarukvalitet.
Automatiserade tester hittar buggar, men deras huvudsakliga syfte är att förhindra att buggar introduceras. Tänk på automatiserade tester som en barriär mot defekter, som förhindrar att buggar återkommer efter att vi har säkerställt att mjukvaran är felfri. Med bra och kompletta regressionstester kommer inga buggar att passera eftersom testerna identifierar felen innan vi ens checkar in koden.
Om de automatiserade testerna är relativt små (det vill säga att vi testar ett beteende per test) kan vi snabbt identifiera var felet finns genom att se vilket test som misslyckas. För att uppnå detta måste vi skriva tester för alla möjliga scenarier och täcka varje enhet i mjukvaran. Testerna får aldrig innehålla tvetydigheter och bör vara små och enkla att förstå.
Automatiserade tester kan tydligt visa hur koden ska fungera genom att indikera det förväntade resultatet av ett eller flera uttryck. Om vi vill veta hur systemet gör något kan vi starta en debugger, köra testet och stegvis se hur koden fungerar. Enhetstester fungerar som en form av dokumentation för systemet.
Att ändra äldre kod är riskabelt eftersom vi ofta inte vet vad vi kan råka förstöra, och det är också svårt att veta om vi faktiskt har gjort det! Vi måste arbeta mycket långsamt och noggrant samt genomföra en hel del manuell analys innan vi gör några ändringar.
Men när vi arbetar med kod som har en automatiserad testsvit kan vi arbeta mycket snabbare. Testerna fångar oväntade bieffekter av ändringar och meddelar oss om vi har orsakat några problem. På så sätt fungerar de automatiska testerna som ett skyddsnät som gör att vi vågar ta chanser.
Vi behöver vara försiktiga så att vi inte introducerar nya typer av problem i systemet till följd av automatiserad testning. Håll testkoden separat från produktionskoden för att undvika att skapa test-specifika beroenden i systemet (särskilt viktigt för enhetstester). All test-specifik kod och alla bibliotek ska endast länkas in av testen och enbart i testbygget och testmiljön. Testberoenden och testkod får aldrig finnas med i den slutgiltiga koden när den byggs för produktion.
Det finns fyra specifika egenskaper som gör automatiserade tester enkla att köra. Med dessa fyra egenskaper kan du enkelt klicka på en knapp (eller ännu bättre, trigga testerna automatiskt) för att få värdefull feedback från testerna:
Testerna måste vara fullt automatiserade så att de kan köras utan ansträngning.
Testerna måste vara självutvärderande så att de kan upptäcka och rapportera fel utan manuell inspektion.
Testerna måste vara repeterbara så att de kan köras flera gånger med samma resultat.
Varje test ska vara oberoende så att det kan köras på egen hand.
Ett test som kan köras utan någon manuell inblandning är ett fullt automatiserat test. Att uppfylla denna egenskap är en förutsättning för att kunna uppfylla de andra.
Ett självutvärderande test kan koda in all information som behövs för att verifiera att det förväntade resultatet är korrekt. Testet meddelar oss endast när resultatet inte har godkänts; som en följd av detta kräver en godkänd testkörning ingen manuell insats.
Ett repeterbart test kan köras om och om igen och ger fortfarande exakt samma resultat utan någon mänsklig inblandning eller analys mellan körningarna.
När vi ändrar beteendet i en del av systemet bör vi förvänta oss att endast ett litet antal tester påverkas av våra ändringar. En av fördelarna med testautomatisering är att underlätta förändringar. Vi bör därför alltid sträva efter att våra tester inte gör det motsatta – det vill säga försvårar förändringar. Testerna bör kräva minimalt underhåll när systemet utvecklas och förändras.
Fokusera på testerna snarare än på hur de faktiskt kodas. Det innebär att testerna måste vara enkla – lätta att läsa, skriva och underhålla. Vi bör sträva efter att verifiera en enda förutsättning per test genom att skapa en separat testmetod för varje unik kombination av förutsättningar. Varje testmetod bör testa systemet genom en enda väg i systemet.
Ett bibliotek med hjälpfunktioner som bygger upp ett domänspecifikt testspråk gör det möjligt för den som skriver testkoden att uttrycka de koncept som ska testas, utan att behöva översätta sina tankar till mer detaljerad kod.
Håll testkoden separat från produktionskoden (behåll strukturen och logiken från produktionskoden men i en parallell struktur). Varje test bör fokusera på ett enskilt problem för att undvika komplicerade och otydliga tester.
Skillnaden mellan ett test och ett bra test kan vara svår att definiera. I denna checklista har jag delat med mig av 12 egenskaper för god testautomatiseringspraxis, vilket i sin tur resulterar i tester som är enkla att skriva och underhålla – två faktorer som är mycket viktiga för ett system.