Automatisering av tester är vardag på många företag idag. Vad många upplever är dock testsviter som inte inger det förtroende som eftersöks, och tester som går sönder så fort koden ändras. Det beror ofta på test som fokuserar på implementationsdetaljer snarare än beteende. Med det menas att testet bryr sig mer om hur applikationen är byggd än om vad den är menad att göra. För användaren gäller det motsatta, nämligen att applikationen fungerar som tänkt oavsett hur. Vad krävs då för att skapa tester som tänker som en användare?
Slutanvändaren är personen som kommer interagera med användargränssnittet i din slutprodukt. Hen navigerar via tillgängliga element i exempelvis en webbläsare. För att ett test ska fungera på samma sätt behöver vi se till att varje handling som testet utför är tillgänglig ur personens perspektiv. Det räcker inte att en knapp kan tryckas på, den behöver också vara synlig och tydligt avisera ett syfte.
Att låta testet hitta en Logga in-knapp via klassnamn som “button” eller “btn” skapar problem då flera element kan ha samma klass. Testet bryr sig dessutom om att det är just ett knappelement som tillhandahåller funktionen. Om vi istället söker efter ett element med texten “Logga in” händer flera positiva saker. Testet söker likt användaren efter en text som aviserar syfte, och kommer misslyckas även om elementet finns men inte förmedlar det syftet. Testet bryr sig inte längre om vad för typ av element som förmedlar funktionen och är således mer robust mot kodändringar. Att hålla sig till denna metod gör också att applikationen utvecklas på ett sätt som säkerställer användarvänlighet, även för personer som använder hjälpmedel som skärmläsare och dylikt för att navigera.
Test som rör sig på komponentnivå är naturligtvis mer kodnära, men om du tänker på en komponent som en ‘black-box’ som får en input och ger en output så har du ett beteende att testa. Verifiera att komponenten får korrekt data för att kunna utföra sin uppgift, och om så är fallet, att den också ger korrekt output. Hur det går till är i det här fallet ointressant, för vi har redan säkerställt att den här delen av vårt system fungerar som det ska. Vi kan också ändra implementationen utan att skriva om testet eftersom beteendet förblir detsamma.
Om dina tester gör något som en av dessa användare inte gör så har du skapat en tredje användare, nämligen testet själv. Vilket inte tillför något värde.
Ett knep för att skriva automatiska test som tänker som en användare är att skriva ner instruktioner för ett manuellt test först. Sen automatisera det flödet!
1. Gå in på en hemsida
2. Skriv in användarnamn i fältet som heter ‘Användarnamn’
3. Skriv in lösenord i fältet som heter ‘Lösenord’
4. Klicka på knappen som heter ‘Logga in’
Här står det ingenting om var i HTML-strukturen dessa element befinner sig, eller vilka anrop som sker mot API, eller vilken font som används. För jag som användare känner inte till det och behöver heller inte veta. Däremot skulle testet fallera om strängarna bytte plats, eller om ett element skyms av en popup.
Med några enkla knep går det att skriva automatiska test som verifierar funktion och beteende snarare än implementationsdetaljer. Testsviterna blir mer robusta mot omstruktureringar i koden och skapar större förtroende för att applikationen fungerar som tänkt.