Automatiserad integrationstestning är din bästa plåga

2012-02-15 Artikelbanken Test Läst 11211 gånger

Integration är mer eller mindre problematisk i alla projekt och det är ofta i integrationerna som du hittar fel sent i projektet. Det är därför en viktig framgångsfaktor att utföra automatiserade integrationstester på ett omfattande och effektivt sätt under hela systemets livscykel. Varför är det då ovanligt att man automatiserar integrationstesterna? Svaret är på denna fråga är mycket enkelt – SMÄRTA! Det är helt enkelt smärtsamt svårt, tidsödande och kostsamt att automatisera integrationstesterna om du inte gör det med rätt syfte, fokus och angreppssätt. Rätt utfört så blir automatiserade integrationstest den dagliga hälsokontroll av ditt system och av din testmiljö som så många projekt efterfrågar och desperat längtar efter. Vi kommer i denna artikel diskutera varför dessa hälsokontroller är så viktiga och hur du gör för att undvika några av de värsta fallgroparna.

Automatiserade integrationstester är som en hälsokontroll

Automatiserad integrationstestning är som ovan nämnt ofta en plåga, men det är en mycket viktig plåga. Orsaken till att det lätt blir en plåga är att ju bredare omfattning dina automatiserade tester har, desto fler problem kommer du att stöta på. Du måste dock ha i minnet att dessa problem är "verkliga" problem som du ändå kommer att ställas inför under utveckling, test eller i värsta fall när applikationen eller systemet produktionssatts. Automatiserad integrationstestning belyser dessa problem med en obarmhärtig tydlighet och kan därför uppfattas som något negativt. Dessa tester är i själva verket nyckeln till att undvika att hitta integrationsproblemen i produktion eller i sena testfaser i stället.

När ett automatiserat integrationstest fallerar - och de kommer att fallera ofta (exempelvis när ett beroende system oväntat har förändrats) så är det inte bara en signal på att just detta test inte gick bra. Det är också en tidig varning om att systemet eller miljön inte är helt konsistent. Tänk som sagt, på automatiserad integrationstest som en hälsokontroll för ditt system och för din testmiljö. 

Hälsokontroller på ditt system genom automatiserade integrationstester har faktiskt flera likheter med just hälsokontroller hos läkaren:

  • De tar tid att utföra
  • Du måste få hjälp av en expert
  • Du får alltid veta otrevliga sanningar
  • De hittar felen innan det är för sent
  • De hittar felen medans de fortfarande är lätta att åtgärda
  • De är kostsamma

Resten av artikeln tänkte jag ägna åt att diskutera de vanligaste problemen och vad vi kan göra för att lindra smärtan. Det är lätt att bara se problemen och tänka att det inte är mödan värt att automatisera integrationstesterna. Jag hoppas därför att du är inställd på att det är en framgångsfaktor att utföra integrationstester och ser problemen som små farthinder på vägen mot att få kontroll på ditt systems hälsa.

Den värsta plågan

Delade databaser är kanske den mest plågsamma aspekten av integrationstestning. Om vi låtsas att vi testar ett resebokningssystem där man kan söka efter resor respektive boka resor så blir problematiken tydlig.

När vi kör ett test som söker efter en samling av hotell som balanserar på en sandig ö i Maldiverna, så har vi en förväntan på att sökningen alltid genererar samma uppsättning hotell. Det är en rimlig förväntan! Ett test behöver konsekventa och förutsägbara data för att kontrolleras mot förväntade resultat. Men vad händer om någon annan uppdaterar samma databas med en ny uppsättning av hotell? Testet kommer att fallera på grund av något utanför din kontroll.

En lista över hotell bör vara ganska statisk så problemet är kanske hanterbart, men problemet kan förvärras när data är mer dynamiskt som exempelvis en kunds saldo i varukorgen. Om vi i ett testscenario utför en operation som uppdaterar saldot, så vill vi i nästa teststeg kontrollera i databasen att saldot uppdaterades korrekt. Detta är inga konstigheter som bör vålla några bekymmer rent automatiseringstekniskt. Problemet är att om någon annan i det ögonblicket utför andra testkörningar, som ändrar saldot till något annat, så drar det undan mattan under fötterna på vårt test. Tester som körs mot en gemensam databas är därför oförutsägbara. 

Hur löser vi detta?

Ett frestande svar är att ta en kopia av databasen att göra våra tester mot. Detta är dock inte alltid praktiskt möjligt. Ett annat enkelt svar är att köra integrationstesterna mindre ofta, och bara köra dem varje natt vid två-tiden eller så. I själva verket är den senare tanken en viktig insikt om automatiserade integrationstester. De kan inte köras i samma "fritt fram för allt och alla, hela tiden"-anda som automatiserade enhetstester körs, utan de måste köra under mer kontrollerade former.

Men vi har fortsatt problemet med att informationen i databasen ser olika ut vid början av varje test. Ur ett testdata-perspektiv underlättar det därför att tänka på varje integrationstest som ett mycket stort enhetstest. I automatiserade enhetstester så strävar vi alltid efter att påverka en avgränsad del av den totala databasen. Ett välskrivet enhetstest börjar därför med att förbereda databasen med de testdata som behövs för att utföra just det testet. På samma sätt så är det en bra idé att starta varje integrationstest med en rutin som skapar en "test-sandlåda" som innehåller precis de data som behövs för testet. Testet blir då mycket stabilt och kan köras i delade databaser utan att vara beroende av ett specifikt läge på testdatat.

Ett vanligt fel som vi ofta ser är att man försöker återställa databasen efter varje test. Det låter kanske konstigt att det skulle vara ett fel, det verkar ju så bra i vid en första tanke. Tänker vi en gång till så inser vi att om ett test måste rensa upp databasen efter sig för att det skall kunna köras nästa gång, så förlitar vi oss på att skriptet alltid går bra. Om testet fallerar så är sannolikheten hög  att rensningen inte utförs till punkt och pricka. Detta leder till att om rensningen misslyckades förra gången skriptet kördes, så kan testet inte köras igen utan att en manuell upprensning görs. Det är därför mycket enklare att köra ett "setup script" som skapar en ”test-sandlåda” i början av varje testscenario, som om vi diskuterade i stycket ovan. 

Multi-team projekt

En annan svårighet är att underhålla och förvalta automatiserade integrationstester i agila organisationer som har  parallella team. Jag ska försöka förklara varför genom att ge ett enkelt exempel.

Team A tillhandahåller ett gränssnitt som används av Team B:s klient. Team A ändrar plötsligt gränssnittet och därmed slutar Team B:s klient att fungera, eftersom Team A har ”glömt” att informera om att gränssnittet kommer att förändras. Naturligtvis kommer detta medföra att ett automatiserat test fallerar.

Detta kan ses som ett exempel på varför automatiserade integration tester är så sköra, men i själva verket är det ett exempel på att automatiserade tester ger en tidig varning om att systemet inte är konsistent. Vår hälsokontroll har helt enkelt hittat en risk innan den blivit till ett stort problem. Detta är alltså inte en svårighet för automatiserade integrationstester utan en av de stora vinsterna och testet har därför varit värdefullt för oss. 

De automatiserade testerna bryter alltid bygget

Testerna kommer som vi tidigare diskuterat alltid att vara beroende av externa system och mer eller mindre beroende av att testdatat är i ett känt tillstånd, för att inte nämna andra oförutsägbara händelser som att två personer kör samma testfall samtidigt, mot samma databas. Allt detta kan bryta ett bygge om vi kör de automatiserade integrationstesterna som en del av den vanliga byggprocessen. Att bryta byggen är både dyrt och impopulärt bland övriga teammedlemmar så den PR:en undviker vi gärna.

Att exekvera de automatiserade integrationstesterna kan ofta ta flera timmar vilket även det gör att det är olämpligt att ha dem i den vanliga byggprocessen. Vem orkar vänta flera timmar på ett bygge när det egentligen inte behövs? Kör därför inte de automatiserade integrationstesterna som en del av din vanliga byggprocess utan schemalägg dem separat - gärna när det för övrigt är så lugnt som möjligt i testmiljön! För att testerna ständigt ska hållas uppdaterade och vara den hälsokontroll som vi vill, så krävs det dock att de körs ofta och regelbundet.

Sparar tid och pengar

Jag hoppas att du håller med mig om att de problem vi just har beskrivit inte bara är begränsade till automatiserade integrationstester. De är typiska för systemutveckling i allmänhet och de automatiserade integrationstesterna lyfter bara fram problemen tydligare och tidigare vilket sparar tid och pengar i slutändan.

För att återkomma till parallellen med hälsokontroller: detta är precis på samma sätt som när du får veta att du har för höga kolesterolvärden. Det är inte hälsokontrollens fel att de är höga, utan i stället så borde vi vara tacksamma att hälsokontrollen upptäckte problemet i tid så att vi kan börja leva lite hälsosammare.

Sammanfattning

Automatiserade integrationstester är nyckeln till att undvika integrationsproblem i produktion eller i sena testfaser. Rätt utfört så blir dessa tester den dagliga hälsokontroll av ditt system och av din testmiljö som så många projekt efterfrågar och desperat längtar efter. Tänk därför på att:

  • Starta varje automatiserat integrationstest med en rutin som skapar en "test-sandlåda" som innehåller precis de data som behövs för testet.
  • Inte förlita dig på att göra en databas återställning efter varje test, låt istället ”test-sandlådan” skapa och sätta upp testdata åt dig.
  • Inte köra de automatiserade integrationstesterna som en del av din vanliga byggprocess, utan schemalägg dem separat.

Nästa steg

Vi på Konsultbolag1 hjälper dig gärna med att utvärdera om Ert system/applikation/projekt lämpar sig för automatiserade integrationstester och hur man på bästa sätt går till väga vid införandet.

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln