Hvad er en god integrations test

Tags:    java junit database test

Hej allesammen

Jeg har et spørgsmål, da jeg er ved at 'øve' mig i at skrive gode integrations tests. Men hvad er egentlig en god test (her tænker jeg mest på integrationstesten).

Er det vigtigt at teste at de test data man får tilbage fra databasen svarer til det der er i hver enkelt kolonne, eller er det nok bare at teste at man har fået et objekt (en række) fra databasen og hvis man henter flere rækker så lige tjekke at man har mere end en række i sit array.

Jeg spørger mest fordi jeg ønsker at vide hvor langt ned i detaljer man skal gå i specielt sin integrationstest.

Det ville være rart at høre og evt. også se nogle af jeres eksempler, på hvad i mener en god integrations test er for noget.

Hvis nogle er interressede i at se de integrations test jeg har lavet i mit projekt indtil videre, er i velkomne til at kigge på min kode. Den er at finde på GitHub, og i skal nok vælge issue10 branchen for at få den nyeste version indtil videre (det kan selvfølgelig nå at ændre sig)

Mvh
Martin Rohwedder



Indlæg senest redigeret d. 28.11.2012 23:51 af Bruger #4487
7 svar postet i denne tråd vises herunder
4 indlæg har modtaget i alt 24 karma
Sorter efter stemmer Sorter efter dato
Hej Martin.
Integrations test har til formål at teste at det du integrerer til fungere som forventet. Og skal være total uafhængig af den kode du har lavet i din service.

Har lavet integrations test et par gange. Og det er selvfølgelig da helt at foretrække at også at tjekke om det returnerede data er korrekt hvis muligt.

Men som minimum bør du teste alle alternative scenarier - eksempelvis output ved forkert input osv.

Præcis hvor meget du går ned er op til dig selvfølgelig. Men mange foretrækker at få nogenlunde fuld code-coverage (hvilket selvfølgelig kan være svært at vide om manhar, hvis man tester en integration man ikke har koden på)

Hvis du har koden til integrationen, så prøv at bruge emmea coverage tool til at teste om din tes dækker koden ordenligt


Code coverage er vel til unit test og ikke til integrationstest? Da man i en integrationstest er interesseret i hvorledes ens elementer arbejder sammen uden at have drivers og stubbe. Coverage er for mig at se irellevant i den sammenhæng.

Typisk skelner man mellem en top-down eller en bottom-up tilgang (i princippet også en big bang - men det er ret voldsomt). Ved top down har du en driver der simulerer en bruger (dine test cases) og resten af systemet er koblet "rigtigt" sammen, med databaser osv. Du vil starte med at stubbe dine komponenter højt oppe, og når de er testet korrekt flytter du dine stubbe nedad og inkluderer således flere og flere af de "rigtige" komponenter.

Bottom op er modsat, hvor du starter lav med dine drivers og arbejder dig op.

(giver det mening?)





Hej Martin.
Integrations test har til formål at teste at det du integrerer til fungere som forventet. Og skal være total uafhængig af den kode du har lavet i din service.

Har lavet integrations test et par gange. Og det er selvfølgelig da helt at foretrække at også at tjekke om det returnerede data er korrekt hvis muligt.

Men som minimum bør du teste alle alternative scenarier - eksempelvis output ved forkert input osv.

Præcis hvor meget du går ned er op til dig selvfølgelig. Men mange foretrækker at få nogenlunde fuld code-coverage (hvilket selvfølgelig kan være svært at vide om manhar, hvis man tester en integration man ikke har koden på)

Hvis du har koden til integrationen, så prøv at bruge emmea coverage tool til at teste om din tes dækker koden ordenligt



Jeg synes det du beskriver Theis lyder mest som en unit test. I en unit test vil man helst kun teste en metode, og har den metode afhængigheder på andre metode kald, så vil man typisk lave en mock/stub på denne for at kunne teste ens specifikke metode.

Ved én integrations test vil jeg mene er man interesseret i at vide får man det data man forventer når man kalder en service/webservice/database. Så i dit tilfælde Martin vil jeg egentlig lave en unit test med junit og så lave en assertion imod det objekt der kommer fra din database med det forventede resultat.



Dine integrationtests bruger du til at teste dine services/repositories, og til at se om dine komponenter spiller sammen. Det du bør teste er, om de objekter du forventer at få tilbage, matcher dem du rent faktisk får tilbage. Derudover bør du også teste dine save/merge/delete metoder, og husk at flushe før du kører dine asserts, så dine statements rent faktisk bliver eksekveret på databasen.

Sidst, men ikke mindst, husk at lave dine integrationtests transactional, således at du kan rulle samtlige ændriger i databasen tilbage efter fuldførelse af tests.

Anvender du noget bestemt framework? Eller arbejder du med ren JDBC?



Er der slet ingen der laver integrations test??



Anvender du noget bestemt framework? Eller arbejder du med ren JDBC?
Jeg anvender spring frameworket... Er stadig ved at lære det, så derfor har jeg ikke sprunget mig ud i springs transacatinal modul endnu.



Spring giver nogle fantastiske muligheder indenfor integrationtests. Hvordan tilgår du din database? Bruger du JDBCTemplate, eller evt. et ORM framework som f.eks. Hibernate eller JPA?

På mit arbejde anvender vi Spring og Spring MVC sammen med JPA (eclipselink) og MyBatis. Spring giver nogle rigtig gode muligheder indenfor integrationtests: http://static.springsource.org/spring/docs/3.0.0.M3/reference/html/ch10s03.html

Alt efter hvad du bruger på databasesiden, er der forskellige ting som Spring integrationtests kan gøre for dig, men det bedste ved det er, at du har fuld adgang til alle beans fra din application context, og at du derfor ikke behøver at mocke noget som helst (ikke at du ville gøre det i en integrationtest). Og især de annotation-baserede muligheder vil du blive glad for.



t