Ett tag innan jul höll jag i en kort presentation för min arbetsgrupp om enhetstester i Java för att få igång en diskussion över hur vi ska förhålla oss till sådana. Jag minns att jag sprang på ett par intressanta fynd när jag samlade ihop material till presentationen och ja, det är väl sånt man lägger upp på sin blogg I guess?

Det största fyndet var helt klart Michael Feathers bloggpost – författaren till den eminienta boken Working Efficiently with Legacy Code – som bjuder på en fin definition av vad ett enhetstest är. Men vänta lite nu, om jag kokar ihop ett exekverbart JUnit test, har jag då inte författat ett enhetstest? Svaret (enligt Feathers definition) är nej om:

• testet arbetar mot databasen
• testet kommunicerar över nätverket
• testet arbetar mot filsystemet
• testet inte kan köras parallellt med andra tester
• man måste göra speciella saker med miljön (till exempel redigera konfigurationsfiler) för att köra testet

Okej, så även om jag skriver mina tester med hjälp av ramverk såsom JUnit är de inte alltid enhetstester. Men att skriva tester för kod som arbetar mot någon form av databas kan väl ändå vara värdefullt? Absolut, men då gäller det att vara medveten om att man testar kodens integration med den mjukvaran/biblioteket/whatever och inte kodens beteende. Att testa hur kod lirar tillsammans med andra moduler och komponenter kallas passande nog för integrationstester.

Karaktäristiskt för integrationstester är att de är tidskrävande, vilket också är en viktig poäng med att skilja enhetstester och integrationstester åt. Enhetstester är något man kör varje gång man bygger projektet medan integrationstester är något som körs mer sällan, t ex som ett schemalagt jobb.

Slutligen vill jag dela med mig av en kul anekdot i ämnet test coverage. Varsågoda!