Indhold
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.
Dato | Ansvarlig | Beskrivelse |
---|---|---|
26/2-2018 | KvalitetsIT | Initiel version |
Reference | Beskrivelse |
---|---|
LAR | Lægemiddelallergiregisrering |
Følgende tests er afviklet som en del af udviklingen af LAR.
Der henvises i øvrigt til LAR - Guide til udviklere 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 - Guide til udviklere).
Integrationstestene for LAR er implementeret vha JUnit, og er beregnet til afvikling mod en kørende udgave af LAR.
For at integrationstesten kan eksekveres med success skal CVR 46837428 være whitelisted i samtykke administration.
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 automatisk, da det vil være meget omstændigt. Efter at integrationstesten er kørt på test serveren bør MinLog tjekkes manuelt for at se at den i properties angive tekst er kommet korrekt ind, også med de specielle danske bogstaver. Pt er denne tekst: "Medicin intolerens læst (ÆæØøÅå)".
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 (CAVE servicens 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.
Testen hentes fra https://svn.nspop.dk/svn/kvalitetsit/cave-performance
Arosii har beskrevet framework og krav i en installationsvejledning. Denne findes i projektet i folderen performance/doc/installationsvejledning.txt. Denne bør læses, hvis man ikke har kendskab til deres framework.
I folderen tests/larservice/src/test/jmeter/performancedata findes et mysql database dump, som skal importeres ind i en tom database til CAVE servicen.
Der skal være en kørende version af LAR og CAVE servicen, man kan teste imod. Og host.properties skal være sat korrekt op jf. arosiis performance test framework. Et eksempel på host.properties kan ses i filen performance/kit-vagrant/ansible/config/host_lar.properties.
Når databasen er på plads, servicene kørende og testen configureret kan følgende køres:
run_test.sh -h hosts.properties -p 9012 larservice listallergy test test900
(distributionen test900 kører 15 minutter, der findes også kørsler til 10 sekunder (test10) og 1 minut (test60))
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.