Indhold

1. Introduktion

1.1. 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.

• 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ø
• Vurdering af historiske data: På et par data samples er der kørt indlæsning gennem LAR service interfacet 

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

1.2. 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.

1.3. Dokument historik

1.4. Definitioner og referencer

2. Afviklede komponenttest

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.

2.1. 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/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:

• 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.

2.1.1. Code Coverage

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

2.2. 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.

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:8082/lar/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.

2.2.1. Kørsel af integrationstest mod lokalt kørende service

Udfør følgende trin, hvis du ønsker at køre integrationstest mod lokal version deployed vha. docker-compose (Se detaljer i udvikler guides til LAR og CAVE service)

1. Tjek source ud til LAR og CAVE servicene
2. Byg servicene
3. Start CAVE servicen lokalt med docker-compose
4. Start LAR servicen lokalt med docker-compose
5. Kør mvn test -Pintegration-test   -Dconsentadministration.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/consent-administration/service -Dlarservice.wsdl=http://localhost:8082/lar/MedicationAllergyService?wsdl

2.2.2. 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
3. Som en sundhedsperson, vil jeg opdatere medicin-allergioplysninger for en patient, så oplysningerne bliver tilgængelige på tværs af parterne i sundhedsvæsenet

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
  • angivelse af om historik ønskes eller ej
    • Uden historik returneres kun aktive allergier
    • Med historik er det 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 3
  • en eksisterende allergi for en given patient kan opdateres, når den har status aktiv
  • patient kan ikke opdateres
  • kun seneste version af allergien kan opdateres
  • alt historik gemmes
• Sletning af lægemiddelallergi-oplysning, user story 1 + 3
  • en eksisterende allergi for en given patient kan ikke slettes. Der opdateres en eksisterende med status inaktiv istedet
• Transformation af LAR oplysninger til CAVE oplysninger, user story 1 + 2 + 3
  • 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 + 3
  • Der er en række status koder, med mere detaljerede status tekster til fejlhåndtering

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 (ÆæØøÅå)".

2.2.2.1. Registrering

1. registrering af allergi med uuid - postivt udfald
   • input: gyldig allergi med uuid
   • udfald: status ok, værdier i allergi som forventet
   • test: U1T1testAtAllergiKanOprettesPaaLovligtCprNummerUuidMedsendes
2. registrering af allergi uden uuid - positivt udfald
   • input: gyldig allergi uden uuid
   • udfald: status ok, uuid er udfyldt på registreret allergi 
   • test: U1T2testAtAllergiKanOprettesPaaLovligtCprNummerUuidMedsendesIkke
3. registrering af allergi med eksisterende uuid - negativt udfald, genbrug af uuid ikke tilladt
   • input: gyldig allergi med eksisterende uuid
   • udfald: status valideringsfejl, allergien er ikke gemt
   • test: U1T3testAtAllergiIkkeKanOprettesNårEksisterendeUuidAnvendes
4. registrering af allergi med formål at afslutte (slettemuligheden) - negativt udfald
   • input gyldig allergi med status inaktiv (forudsætning, der findes allerede en aktiv)
   • udfald: status valideringsfejl, og der findes fortsat kun den oprindelige allergi som aktiv
   • test: U1T4testAtAllergiIkkeKanOprettesOgEfterfølgendeInaktiveresUuidMedsendes
5. registrering af ugylding allergi - negativt udfald
   
   • input: ugyldig allergi, substance code mangler i input
   • udfald: status valideringsfejl, allergien er ikke gemt
   • test: U1T5testAtAllergiIkkeOprettesNårSubstanceCodeMangler

2.2.2.2. Læsning

1. læsning af allergi - positivt udfald, ingen historik
   • input: patient uden negativ samtykke, ingen værdispring, ingen historik
   • udfald: status ok, patientens nyeste version af allergier med status aktiv hentes
   • test: U2T1testAtToAllergierKanHentesForPatientUdenNegativeSamtykkerUdenBrugAfVaerdiSpring
2. læsning af allergi - negativ samtykke uden værdispring, ingen historik - negativt udfald
   • input: patient med negativ samtykke mod kaldende sundhedsperson, ingen værdispring, ingen historik
   • udfald: status negativ samtykke, ingen allergier vises
   • test: U2T2testAtAllergierIkkeKanHentesForPatientMedNegativSamtykkeModSundhedsPersonenDerForetagerFremsoegningUdenBrugAfVaerdispring
3. læsning af allergi - negativ samtykke med værdispring, ingen historik - positivt udfald
   • input: patient med negativ samtykke mod kaldende sundhedsperson, værdispring, ingen historik
   • udfald: status ok, patientens nyeste version af allergier med status aktiv hentes
   • test: U1T3testAtAllergierKanHentesForPatientMedNegativSamtykkeModSundhedsPersonDerForetagerFremsoegningMedBrugAfVaerdispring
4. læsning af allergi - negativ samtykke mod anden person, ingen historik, positivt udfald, ingen historik
   • input: patient med negativ samtykke mod anden person end kaldende sundhedsperson, ingen værdispring
   • udfald: status ok, patientens nyeste version af allergier med status aktiv hentes
   • test: U2T4testAtAllergierKanHentesForPatientMedNegativSamtykkeModEnAndenSundhedsPersonenEndDenDerForetagerFremsoegning
5. læsning af allergi - dataspecifik negativ samtykke uden værdispring, ingen historik, delvist positivt udfald
   • input: patient med dataspecifikt negativ samtykke, ingen værdispring, ingen historik
   • udfald: status succes men dataspec., et udsnit af patientens nyeste version af allergier med status aktiv hentes
   • test: U2T5testAtAllergierForRegistreringerPaaSorkodeHvorPatientHarDataSpecifiktNegativtSamtykkeFiltreresFraNaarDerIkkeBrugesVaerdispring
6. læsning af allergi - dataspecifik negativ samtykke med værdispring, ingen historik, postivt udfald
   • input: patient med dataspecifikt negativ samtykke, værdispring, ingen historik
   • udfald: status success, patientens nyeste version af allergier med status aktiv hentes
   • test: U2T6testAtAllergierForRegistreringerPaaSorkodeHvorPatientHarDataSpecifiktNegativtSamtykkeIkkeFiltreresFraNaarDerBrugesVaerdispring
7. læsning af allergi med ikke eksisterende patient, ingen historik - postivt udfald
   • input: patient som ikke har allergier registreret, ingen værdspring, ingen historik
   • udfald: status ok, der er ingen allergier at hente
   • test: U2T7testAtIngenAllergierHentesForPatientUdenNegativeSamtykkerUdenBrugAfVaerdiSpring
8. læsning af allergi med manglende søgekriterie, ingen historik - negativt udfald
   • input: ingen patient, ingen værdispring, ingen historik
   • udfald: status valideringsfejl, ingen allergier returneres
   • test: U2T8testAtIngenAllergierHentesForBlankPatientUdenBrugAfVaerdiSpring
9. læsning af allergi, med historik , allergi har historik og er inaktiv - positiv udfald
   1. input: patient uden negativ samtykke, ingen værdispring, historik
   2. udfald: status ok, patientens allergier med alle status hentes i alle versioner
   3. test: U2T9testAtAllergierKanHentesMedHistorik
10. læsning af allergi, ingen historik (selvom der er en del historik) - positiv udfald
    1. input: patient uden negativ samtykke, ingen værdispring, ingen historik
    2. udfald: status ok, patientens nyeste version af allergier med status aktiv hentes
    3. test: U2T10testAtAllergierKanHentesUdenHistorik
11. læsning af allergi, ingen historik (selvom der er en del historik og inaktiv) - positiv udfald
    1. input: patient uden negativ samtykke, ingen værdispring, ingen historik
    2. udfald: status ok, der er ingen allergier at hente
    3. test: U2T11testAtAllergierIkkeKanHentesUdenHistorikNaarInactive
12. læsning af allergi uden angivelse af om historik (som ved ingen historik) - positiv udfald
    1. input: patient uden negativ samtykke, ingen værdispring, med historik
    2. udfald: status ok, patientens nyeste version af allergier med status aktiv hentes
    3. test: U2T11testAtAllergierKanHentesUdenHistorikDefault

2.2.2.3. Opdatering

1. opdatering af allergi med uuid - postivt udfald
   • input: gyldig eksisterende allergi med uuid
   • udfald: status ok, værdier i allergi opdateret som forventet
   • test: U3T1testAtAllergiKanOpdateresPaaLovligtCprNummer
2. opdatering af allergi uden uuid - negativt udfald
   • input: gyldig eksisterende allergi uden uuid (findes reelt ikke da uuid er null)
   • udfald: status fejl, allergien er ikke opdateret
   • test: U3T2testAtAllergiIkkeKanOpdateresPaaLovligtCprNummerUuidMedsendesIkke
3. opdatering af allergi med ukendt uuid - negativt udfald
   • input: gyldig eksisterende allergi med ikke eksisterende uuid (findes reelt ikke da uuid ikke findes)
   • udfald: status fejl, allergien er ikke opdateret
   • test: U3T3testAtAllergiIkkeKanOpdateresNaarIkkeEksisterendeUuidAnvendes
4. opdatering af allergi med patient ændret - negativt udfald
   • input: gyldig eksisterende allergi med opdateret patient
   • udfald: status fejl, allergien er ikke opdateret
   • test: U3T4testAtAllergiIkkeKanOpdateresNaarPatientAendres
5. opdatering af ikke seneste version af allergi - negativ udfald
   • input: gyldig eksisterende allergi med ikke nyeste version id
   • udfald: status fejl, allergien er ikke opdateret
   • test: U3T5testAtAllergiIkkeKanOpdateresNaarIkkeNyesteVersion
6. opdatering af allergi 3 gange og al historik gemmes - postivt udfald
   • input: gyldig eksisterende allergi
   • udfald: status ok
   • test: U3T6testAtAllergiKanOpdateresTreGangeOgHistorikGemmes
7. opdatering af allergi med inaktiv status (slettemarkering) -  postivt udfald
   • input: gyldig eksisterende allergi
   • udfald: status ok
   • test: U3T7testAtAllergiKanOpdateresMedStatusInaktiv
8. opdatering af inaktiv allergi - negativt udfald
   • input: gyldig eksisterende allergi med status inaktiv
   • udfald: status fejl, allergien er ikke opdateret
   • test: U3T8testAtAllergiIkkeKanOpdateresNaarStatusInaktiv
9. opdatering af allergi med invalid data - negativt udfald
   • input: gyldig eksisterende allergi og blank drugid
   • udfald: status fejl, allergien er ikke opdateret
   • test: U3T9testAtAllergiIkkeKanOpdateresPaaLovligtCprNummerNaarDrugidBlankes
10. opdatering af allergi uden versionid - negativt udfald
    1. input: gyldig eksisterende allergi men uden versionid
    2. udfald: status fejl, allergien er ikke opdateret
    3. test: U3T10testAtAllergiIkkeKanOpdateresNaarVersionNull

2.2.2.4. 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.

2.2.2.5. Fejlhåndtering

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

2.2.3. Øvrige krav

2.2.3.1. Test af sikkerhedsaspekter

Udover ovenstående user story drevne teste kontrolleres følgende med forventet negativ udfald

1. Test at Headers mangler i DGWS
   
   • test: S1T1testHeadersMissing
2. Test at Voces afvises
   • test: S1T2testVocesIsRejected
3. Test at ID Card er udløbet
   • test: S1T3testExpiredIdCard

2.3. Performancetests

2.3.1. Test data

2.3.1.1. Eksisterende data

Et forslag til data til performance testen findes attached på dette dokument.

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

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

Før test kørslen skal databasen importeres til en tom fhir database (CAVE servicens database) samt cprSample placeres i sampler biblioteket for integrationstesten

2.3.1.2. Ny data

Ønskes et nyt datagrundlag kan performance data generes fra LAR service projektet. Dette aktiveres via Maven ved følgende kommando eller tilsvarende med justerede parametre:

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.

2.3.2. Udførsel af test

2.3.2.1. Forberedelse

Testen hentes fra https://svn.nspop.dk/svn/components/performance/trunk i den revision, der er angivet for versionen af LAR servicen.

Databasen klargøres. Tom allergi (fhir) database, hvor cavedatebasedump.sql er indlæst.

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. 

2.3.2.2. Kørsel

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 lar listallergy test900

(distributionen test900 kører 15 minutter, der findes også kørsler til 10 sekunder (test10) og 1 minut (test60))

2.3.3. Version

'* ' betyder hvilken som helst

2.4. Endurancetests

Denne test indgår som en del af performance testen

2.5. Vurdering af historiske data

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.