Automatisk test och kontinuerlig leverans

Under ett antal år har jag varit med och lagt grunden till många system och utvecklingsmiljöer där automatisk test och build pipelines utgjort viktiga element. Jag har även haft förmånen av att ha arbetat i teamen under en längre tid efter etableringen och den vägen erhållit praktisk erfarenhet av dagligt utvecklingsarbete där automatisk test och täta leveranser ingår.

IMG_20150331_173153

Jag har gjort liknande observationer som Jez Humble gjort och på ett utmärkt sätt beskrivit i boken Continuous Delivery.

För att automatisk test ska kunna fungera och underhållas över tid måste den integreras på ett bra sätt i den normala byggcykeln. Alla utvecklare och testare ska enkelt kunna köra testerna innan commit, och på samma vis som byggpipelinen gör. Testkod och testdata ska självklart också vara incheckat. Alla i teamet oavsett om man jobbar med applikationsutveckling eller testutveckling ska kunna rätta och utveckla testerna. Testerna ska köras automatiskt vid incheckning i kodrepot och om testerna fallerar avbryter man det man höll på med och avhjälper felet. Av detta följer att testutvecklare och applikationsutvecklare måste samarbeta om aktiviteterna.

Om testutveckling sker separat från applikationsutveckling och testutvecklingen ligger före applikationsutvecklingen kommer det alltid att finnas tester som fallerar eftersom funktionaliteten som testas inte är utvecklad än. Och om testutveckling istället ligger efter applikationsutveckling i fas är det stor risk att systemet som utvecklas inte blir testbart. Och under tiden applikationen och automattesterna inte är synkade så är systemet inte releasebart. Alla dessa situationer är oönskade.

De utvecklingsmiljöer jag etablerat de senaste åren har varit Maven-baserade och uppdelade i flera moduler. Den första uppdelningen är en applikationskatalog och en testkatalog. Under testkatalogen lägger jag moduler med olika automatiska tester, uppdelade per verktyg/ramverk samt tjänstestubbar, testdatamoduler m.m.

De vanligaste verktygen för automatisk test jag stött på är:

SoapUI Pro är rätt använt ett bra verktyg för att utveckla automatiska tester mot tjänstegränssnitt.

Selenium fungerar bra så länge man håller sig till smoke-tester av UI där och inte försöker sig på att skriva funktionella tester med anspråk på att täcka upp stora delar av systemets funktionalitet.

Java är fortfarande ett enkelt och effektivt verktyg att skriva funktionella tester med. Man skriver dem med JUnit-ramverket precis som med vanliga enhetstester, men koden kör mot det riktiga systemet som deployas via Maven i Mavens byggcykel. Om man är van vid Groovy istället för Java (i SoapUI använder man Groovy för lite mer avancerade saker) så är det lätt att lägga till en Groovy-modul istället, och fortfarande på JUnit-ramverket och med tillgång till samma stödbibliotek som i Java.

Cucumber fungerar bra och resulterar i trevlig och lättändrad kod, och sympatisk och lättläst rapportering med bra integration i Jenkins via Cucumber plugin. En risk som jag och flera omkring mig också observerat är att man från verksamhetssidan inte tar tillvara på fördelarna som en exekverbar kravspec på den här formen innebär och då blir det bara utvecklare som läser och uppdaterar den vilket innebär att man då lika gärna kan skriva dessa tester direkt i Java eller något annat programmeringsspråk.

För kapacitetstester är JMeter är ett verktyg jag nyfiken att undersöka vidare hur man lämpligast integrerar med Maven och hur det fungerar i längden. LoadUI är ett annat alternativ här som jag ännu bara kört manuellt, alltså ännu inte integrerat i en pipeline.

Spring Boot har jag använt många gånger för att skriva mer eller mindre avancerade tjänstemockar som krävs för automatisk test, både REST- och SOAP-servrar. Mycket effektivt och ändamålsenligt för detta.

Och sist men inte minst: Lamporna

Utan lampor eller liknande synlig och central indikator är det lätt att teamet efter den inledande CI-förälskelsen glömmer CI-statusen och att testjobb fallerar i veckor i sträck.

En för många ny aspekt av automatisk test är att testledaren bör ha kontroll på alla tester, oavsett om de är manuella eller automatiska, och oavsett vem i teamet de är utvecklade av. Gränsen mellan applikationsutvecklare och testutvecklare ska helst vara flytande eller obefintlig.

Om man har krav på sig att följa upp testtäckning mot krav måste detta också ske kontinuerligt, vilket kräver intrimmade procedurer och koll på krav- och testläget.

Vidare ska testledaren ha kontroll på vilka tester som implementeras automatiskt och i vilken modul och vilka som är manuella, ha en idé om vilka manuella tester som ligger på kö för automatisering och ta initiativ till och följa upp att så sker.

Levererar man ofta så behöver man inte ha samma kontroll på aktuell teststatus som annars, eftersom normalläget är att alla tester passerar, lampan är normalt grön. Merparten av testerna måste då vara automatisk och den manuella delen får inte ta lång tid att plöja igenom.

Levererar man till exempel varannan vecka kan man kanske kosta på sig en dags manuell test innan produktion, levererar man varje dag rör det sig kanske om någon timme. Får man en tillräckligt inoljad utvecklings- och leveransmodell slutar man kanske helt att ha en manuell testprocedur innan produktionssättning eftersom man lärt sig att utveckla och testa i små steg från början. Ett extra teststeg på slutet blir då redundant. Och inträffar fel i produktion är man vaken och fixar snabbt felet och skickar ut en rättning. Det går ändå inte att skydda sig helt från produktionssmällar eftersom våra användare och externa system ibland gör helt andra saker än vad vi tänkt oss som ingen testning i världen kan förutse. Bättre då vaka över systemet i drift och att göra det enkelt att skicka ut en rättning. Detta kräver i sin tur en väloljad pipeline hela vägen ut i produktion och nära samarbete med driften. I detta avseende har många fortfarande en bra bit kvar att vandra.

Men å andra sidan, att det finns mycket kul saker kvar att göra är underbart för alla oss som älskar det här jobbet 🙂

IT Consultant at CAG Edge. Cloud and Continuous Delivery specialist, software developer and architect, Node.js, Java.

Publicerad i Continuous Delivery, DevOps, Java, Test

Kategorier

WP to LinkedIn Auto Publish Powered By : XYZScripts.com