Formålet med dette dokument er at beskrive de tests, som er udviklet og afviklet forud for release af LAR servicen.
Følgende typer af test bruges indgår i udviklingsarbejdet:
Unittests: Unittests tester, at de individuelle/isolerede enheder (klasser) i kildekoden virker som de skal.
Integrationstest: Integrationstests afvikles op i mod en kørende LAR service til verifikation af funktion og deployment. Herved verificeres det, at de individuelle enheder kan integreres og arbejde sammen i en kørende service.
Performancetest: Verificerer, at servicen performer med hensyn til svartider og er stabil under et specifikt load.
De i LAR anvendte tests gennemgåes i det følgende.
Dokumentet henvender sig til udviklere og testere.
Læseren forventes at have kendskab til Java software udvikling, herunder unittesting ved anvendelse af JUnit og Maven.
Følgende tests er afviklet som en del af udviklingen af LAR.
Der henvises i øvrigt til LAR Udviklerguide for udførselsvejledning og LAR Testrapport for resultat.
Der findes UnitTests af alle centrale enheder (klasser) i LAR.
Placeringen af disse følger standarden foreskrevet af Maven og er placeret i src/test/java i hvert af LAR servicens moduler.
Unittests er navngivet med navnet på den klasse, som de tester, efterfulgt af Test.
Således ligger unittesten for klassen:
./larservice-cave/src/main/java/dk/nsp/larservice/cave/client/CaveClientConverter.java
implementeret i:
./larservice-cave/src/test/java/dk/nsp/larservice/cave/client/CaveClientConverterTest.java
Unittests er stilmæssigt opbygget på følgende måde:
Unittests er implementeret vha JUnit og kan eksekveres af Mavens standard testplugin SureFire.
Til udregning af testcoverage anvendes Jacoco Maven Plugin (se JaCoCo Maven plug-in).
Testcoverage udregnes i de enkelte Maven moduler i LAR servicen og aggregeres til en samlet rapport i modulet larservice-integrationtest.
Således er en samlet rapport over testcoverage tilgængelig i
./larservice-integrationtest/target/site/jacoco-aggregate/
Der er et mål at test overage er på 80 %. Dog kan det afviges for auto genereret kode. Derfor er code coverage på larservice-types modulet noget lavere end resten.
Unittests og tilhørende udregning af testcoverage udføres som en integreret del af byg af komponenten (se i øvrigt LAR Udviklerguide).
Integrationstestene for LAR er implementeret vha JUnit, og er beregnet til afvikling mod en kørende udgave af LAR.
Integrationstest aktiveres via Maven ved følgende kommando:
mvn test -Pintegration-test -Dconsentadministration.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/consent-administration/service -Dlarservice.wsdl=http://localhost:8065/larservice/MedicationAllergyService?wsdl
Parametrene, der skal sættes er dokumenteret herunder
Property | Beskrivelse |
consentadministration.endpoint | Endpoint til samtykkeadministrationen, der skal benyttes |
larservice.wsdl | URL, der udpeger Larservicens WSDL |
Ved aktivering af integrationstesten vil helbreds/versionsservice afprøves. Denne kaldes også health servicen.
Derudover vil der laves test af oprettelse samt hentning af allergioplysninger via LAR med udgangpunkt i de User Stories og krav som er beskrevet i krav specifikationen.
Formålet med dette afsnit er at forklare, hvordan integrations testens dele er blevet til. Det skal løbende vurderes om krav og integrationstest fortsat hænger sammen.
Der arbejdes med følgende user stories, og disse understøttes af integrations testen.
Derudover er der følgende krav som hver har deres forudsætninger og formål:
For alle user story baserede test forudsættes gyldig DGWS formateret besked og gyldigt SOSI-ID kort.
Minlog og behandler relations service kaldes under integrationstesten, og valideres indirekte ved at en eventuelt fejlsituation vil får LAR servicen til at fejle. Resultatet i selve de 2 services valideres dog ikke, da det vil være meget omstændigt.
Transformering testes som en del af testen "registrering af allergi med uuid - postivt udfald" hvor input og output sammenlignes. Dermed har data ikke ændret sig under transformering fra LAR >> CAVE >> LAR format.
Fejlhåndtering testes som en del af både registrering og læsning, i det test som har negativ udfald.
Udover ovenstående user story drevne teste kontrolleres følgende med forventet negativ udfald
Et forslag til data til performance testen findes sammen med selve performance testen på SVN serveren i projektet: https://svn.nspop.dk/svn/kvalitetsit/cave-performance
/tests/larservice/src/test/jmeter/performancedata/
Databasen indeholder 50.000 allergier, fordelt på ligeså mange patienter.
Før test kørslen skal databasen importeres til en tom allergi database samt cprSample placeres i sampler biblioteket for integrationstesten
Ønskes et nyt datagrundlag kan performance data generes fra LAR service projektet. Dette aktiveres via Maven ved følgende kommando:
mvn test -Pperformancedata-test -Dconsentadministration.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/consent-administration/service -Dlarservice.wsdl=http://localhost:8065/larservice/MedicationAllergyService?wsdl
Vær opmærksom på, at justeringer kan være nødvendige i kildekoden (Modulet larservice-integrationtest, pakken .performancedata, klassen PerformanceTestDataImport.java) omkring antallet af records, fordeling af recorder information samt cpr nummer genereringen).
Der bør køres mod en allergi database med tomme tabeller. Efter kørslen kan listen med cpr numre findes i test resources biblioteket.
[TBD]
[TBD]
Denne test indgår som en del af performance testen
Der er udviklet import test mod historiske data for Novax og Region Midt. Formålet med dette er at se "rigtige" data indlæst i allergi databasen, samt at få en fornemmelse af, hvilken kvalitet historiske data har i forhold til LAR service interfacet.
Import testene findes i modulet larservice-integrationtest, pakken .dataimport og kan aktiveres via Maven ved følgende kommando
mvn test -Pdataimport-test -Dconsentadministration.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/consent-administration/service -Dlarservice.wsdl=http://localhost:8065/larservice/MedicationAllergyService?wsdl
Kørslerne tager udgangspunkt i navngivne filer (se kildekode) som placeres i test resources biblioteket, og disse bliver så læst ind i allergi databasen.
Disse tests bør som udgangspunkt ikke køres igen (hvorfor de indeholder annoteringen @ignore), men forbliver i projektet, som inspiration til alternative fremtidige kørsler. Kildekoden er lavet så den både kan kalde LAR servicen, men også alene indsamle statistik omkring de historiske data for hurtigere afvikling. Så det kan være nødvendigt at justere i kildekoden før en eventuelt kørsel.