Introduktion

Formål

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.

• Vurdering af historiske data: På et par data samples er der kørt indlæsning gennem LAR service interfacet 

Andre typer af tests (ikke en del af udviklingen af LAR):

• Endurancetests, der verificerer at servicen fungerer under længerevarende belastning og ikke har f.eks. memory leaks, som kan udføres i stagning/produktionslignende miljø.

De i LAR anvendte tests gennemgåes i det følgende.

Læsevejledning

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.

2. Afviklede komponenttest

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.

UnitTests

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/sds/larservice/cave/client/CaveClientConverter.java

implementeret i:

./larservice-cave/src/test/java/dk/sds/larservice/cave/client/CaveClientConverterTest.java

Unittests er stilmæssigt opbygget på følgende måde:

• Hver testcase er implementeret som en metode i den relevante testklasse
• Testcasen er navngivet, så det tydeligt fremgår, hvad formålet med testen er
• Kommentarer i testcasen inddeler tydeligt i præcondition (Given), udførsel (When), tjek (Then) som beskrevet f.eks. Martin Fowler: Given-When-Then

Unittests er implementeret vha JUnit og kan eksekveres af Mavens standard testplugin SureFire.

Testcoverage

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 test 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).

Integrationstest til verifikation af funktionalitet og deployment

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

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.

User Stories og krav anvendt

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.

1. Som en sundhedsperson, vil jeg registrere medicin-allergioplysninger for en patient, så oplysningerne bliver tilgængelige på tværs af parterne i sundhedsvæsenet
2. Som en sundhedsperson, vil jeg se medicin-allergioplysninger for en patient, så jeg kan undgå at ordinere medicin, som patienten ikke kan tåle

Derudover er der følgende krav som hver har deres forudsætninger og formål:

• Registrering af lægemiddelallergi-oplysning, user story 1
  • Med og uden Uuid for identifikation
• Læsning af lægemiddelallergi-oplysning, user story 2
  • læsning for en given patient
  • det er op til det modtagene system at sortere i aktive og inaktive allergier
  • negativ samtykke håndteres
  • Der registreres i minlog og behandler relation servicen.
• Opdatering af lægemiddelallergi-oplysning, user story 1
  • en eksisterende allergi for en given patient kan ikke opdateres, der registreres en ny med ændrede data
• Sletning af lægemiddelallergi-oplysning, user story 1
  • en eksisterende allergi for en given patient kan ikke slettes. Der registreres en ny med status inaktiv
• Transformation af LAR oplysninger til CAVE oplysninger, user story 1 + 2
  • LAR servicen modtager et format, som gemmes vha. CAVE servicen som har sit eget format.
• Fejlhåndtering ved kald af LAR servicen, user story 1 + 2
  • Der er en række status koder, med mere detaljerede status tekster til fejlhåndtering

For alle test forudsættes gyldig DGWS formateret besked og gyldigt SOSI-ID kort.

Minlog og behandler relations servicen håndteringen tjekkes ikke at integrationstesten, da dette vil være meget omstændigt.

Registrering

• registrering af allergi med uuid - postivt udfald
  • input: gyldig allergi med uuid
  • udfald: status ok, værdier i allergi som forventet
  • test: testAtAllergiKanOprettesPaaLovligtCprNummerUuidMedsendes
• registrering af allergi uden uuid - positivt udfald
  • input: gyldig allergi uden uuid
  • udfald: status ok, uuid er udfyldt på registreret allergi 
  • test: testAtAllergiKanOprettesPaaLovligtCprNummerUuidMedsendesIkke
• registrering af allergi med eksisterende uuid - negativt udfald, opdatering er ikke tilladt
  • input: gyldig allergi med eksisterende uuid
  • udfald: status valideringsfejl, allergien er ikke gemt
  • test: testAtAllergiIkkeKanOprettesNårEksisterendeUuidAnvendes
• registrering af allergi med formål at afslutte (slettemuligheden) - positivt udfald
  • input gyldig allergi med status inaktiv (forudsætning, der findes allerede en aktiv)
  • udfald: status ok, og der findes både en aktiv og en inaktiv allergi
  • test: testAtAllergiKanOprettesOgEfterfølgendeInaktiveresUuidMedsendes
• registrering af ugylding allergi - negativt udfald
  
  • input: ugyldig allergi, substance code mangler i input
  • udfald: status valideringsfejl, allergien er ikke gemt
  • test: testAtAllergiIkkeOprettesNårSubstanceCodeMangler

Læsning

• læsning af allergi - positivt udfald
  • input: patient uden negativ samtykke, ingen værdispring
  • udfald: status ok, patientens allergier hentes
  • test: testAtToAllergierKanHentesForPatientUdenNegativeSamtykkerUdenBrugAfVaerdiSpring
• læsning af allergi - negativ samtykke uden værdispring - negativt udfald
  • input: patient med negativ samtykke mod kaldende sundhedsperson, ingen værdispring
  • udfald: status negativ samtykke, ingen allergier vises
  • test: testAtAllergierIkkeKanHentesForPatientMedNegativSamtykkeModSundhedsPersonenDerForetagerFremsoegningUdenBrugAfVaerdispring
• læsning af allergi - negativ samtykke med værdispring - positivt udfald
  • input: patient med negativ samtykke mod kaldende sundhedsperson, værdispring
  • udfald: status ok, patientens allergier hentes
  • test: testAtAllergierKanHentesForPatientMedNegativSamtykkeModSundhedsPersonDerForetagerFremsoegningMedBrugAfVaerdispring
• læsning af allergi - negativ samtykke mod anden person, positivt udfald
  • input: patient med negativ samtykke mod anden person end kaldende sundhedsperson, ingen værdispring
  • udfald: status ok, patientens allergier hentes
  • test: testAtAllergierKanHentesForPatientMedNegativSamtykkeModEnAndenSundhedsPersonenEndDenDerForetagerFremsoegning
• læsning af allergi - dataspecifik negativ samtykke uden værdispring, delvist positivt udfald
  • input: patient med dataspecifikt negativ samtykke, ingen værdispring
  • udfald: status succes men dataspec., et udsnit af patientens allergier hentes
  • test: testAtAllergierForRegistreringerPaaSorkodeHvorPatientHarDataSpecifiktNegativtSamtykkeFiltreresFraNaarDerIkkeBrugesVaerdispring
• læsning af allergi - dataspecifik negativ samtykke med værdispring, postivt udfald
  • input: patient med dataspecifikt negativ samtykke, værdispring
  • udfald: status success, patientens allergier hentes
  • test: testAtAllergierForRegistreringerPaaSorkodeHvorPatientHarDataSpecifiktNegativtSamtykkeIkkeFiltreresFraNaarDerBrugesVaerdispring
• læsning af allergi med ikke eksisterende patient - postivt udfald
  • input: patient som ikke har allergier registreret, ingen værdspring
  • udfald: status ok, der er ingen allergier at hente
  • test: testAtIngenAllergierHentesForPatientUdenNegativeSamtykkerUdenBrugAfVaerdiSpring
• læsning af allergi med manglende søgekriterie - negativt udfald
  • input: ingen patient, ingen værdispring
  • udfald: status valideringsfejl, ingen allergier returneres
  • test: testAtIngenAllergierHentesForBlankPatientUdenBrugAfVaerdiSpring

Transformation

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

Fejlhåndtering testes som en del af både registrering og læsning, i det test som har negativ udfald.

Performancetests

Test data

Eksisterende data eksempel

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/

• cavedatebasedump.sql - import script til en fhir database
• cprSample.txt - liste af cpr numre som matcher databasen

Databasen indeholder 50.000 allergier, fordelt på ligeså mange patienter. 

Databasen skal importeres til en tom cave database for test kørslen, og cprSample placeres i sampler biblioteket for integrationstesten

Nyt data eksempel

Ø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 (PerformanceTestDataImport.java) omkring antallet af records, fordeling af recorder information samt cpr nummer genereringen)

Udførsel af test

[TBD]