nxrg_hent

1. Unittests

Der findes UnitTests af centrale enheder (klasser) i NXRG.

Placeringen af disse følger standarden foreskrevet af Maven og er placeret i src/test/java i hvert af NXRG servicens moduler.

Unittests er navngivet med navnet på den klasse, som de tester, efterfulgt af Test.

Således ligger unittesten for klassen:

./nxrg-app/src/main/java/dk/nsp/nxrg/ws/Iti42WS.java

implementeret i:

./nxrg-app/src/test/java/dk/nsp/nxrg/ws/Iti42WSTest.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.

Til udregning af testcoverage anvendes Jacoco Maven Plugin (se JaCoCo Maven plug-in).

Testcoverage udregnes i de enkelte Maven moduler i NXRG og aggregeres til en samlet rapport i modulet nxrg-testreport.

Således er en samlet rapport over testcoverage tilgængelig i

./nxrg-testreport/target/site/jacoco-aggregate

Unittests og tilhørende udregning af testcoverage udføres som en integreret del af byg af komponenten (se i øvrigt NXRG/SDS Patientindex - Guide til Udviklere).

2. Integrationstest til verifikation af funktionalitet og deployment

Integrationstestene for NXRG er implementeret vha Cucumber og JUnit i modulet nxrg-qa, og er beregnet til afvikling mod en kørende udgave af NXRG.

Da man har brug for database adgang for at kontrollere felt migrerings integrationstesten, kan denne kun køres lokalt, hvorfor den er exluded fra de ørige profiler end "local".

Afvikling af Integrationstests aktiveres via Maven ved følgende kommando i modulet nxrg-qa:

mvn verify -Pintegration-test  -Dvariabel=value

Det kræves at følgende properties angives ved afvikling af integrationstesten. De 2 felt migration relaterede properties er kun krævet når man kører test profilen "local".

For nemheds skyld er der angivet følgende profiler (kan angives med -P), med variabeldefinitioner for et givent miljø

Testrapporter kan for integrationstesten genereres som html og json og kan ses i /target/cucumber-reports/cucumber.html og /target/cucumber-reports/cucumber.json

Integrationstesten sender een notifiation til NAS. Denne kan findes via DRG. På Test1 kan det gøres med getMessages vha. pull point: http://test1.ekstern-test.nspop.dk:8080/nas2/pullpoint/service/080d09f8-48af-405c-b55f-f821a773c9c1

2.1. Sammenhæng mellem integrationstests og user stories

I NXRG/SDS Patientindex - Brugerhistorier findes en liste over, hvilke user stories, der er relevante for NXRG. 

Disse brugerhistorier går igen i integrationstestene, da hver brugerhistorie svarer til en integrationstestssuite (feature) i NXRG.

Således findes testscenarier for brugerhistorien 'Registrer Dokumentsæt med ReferenceIdList' i featurefilen:

./nxrg-qa/src/test/resources/dk/nsp/nxrg/test/verification/RegistrerDokumentsaetMedReferenceIdList.feature

Integrationstesten i NasNotificationJob.feature indgår ikke i user stories, da den er drift relateret.

2.2. XDS Toolkit 2: Testing

XDS Toolkit er en samling test tools, der fokuserer på XDS. Denne startes på vha docker-compose filen (tjek om den er udkommenteret, hvis den ikke starter)

Det understøtter tests for en række IHE XDS aktører f.eks Document Registry, Document Repository og flere.

I forhold til NXRG er det relevant at kigge på, hvilke tests, der findes, der fokuserer på Document Registry.

Vælg "alternate" som environment. Test11897 test 1 og 2 fejler ellers.

I menuen i XDS Toolkit kan man vælge "Conformance Tests". Herved fåes et overblik over de forskellige IHE XDS aktøerer. I sektionen vedr. Document Registry er testene grupperet. I forhold til NXRG MVP er det relevant at koncentrere sig om de tests, der ligger i de sektionerne:

• Document Registry / XDS / Required
• Document Registry / XDS / Metadata Update Option
• Document Registry / XDS / On demand Option

For lokal test: værktøjet startes op docker compose setup under ./compose/development og kan herefter tilgåres via: http://localhost:3308/xdstools2/

For udvikling testserver test anvend: https://iheos-toolkit2.nspnxrg.medcom.dk/xdstools2/

Det er ikke alle tests inden for de tre kategorier, som vi forventer at kunne gennemføre i NXRG MVP (vi udbyder f.eks. kun en delmængde af de søgetyper, der findes som en del af ITI-18). Kategorierne og testcases gennemgås nedenfor og relevans krydses af.

Rød=Fejl som skal retttes, gul=accepteret "fejl", grøn=er rettet, lysere rød=stilling ikke taget

3. Performance test

Der laves performance test af regsistry og repository som et hele - dvs det er brugeroplevelsen som sådan, der vurderes.

Testen grupperes logisk i en test suite. Hver trin bør udføres i angivne orden. Og databasen til registry og repository kan med fordel kopieres efter trin 2, sådan at de følgende testtrin kan genkøres, skulle behovet opstå.

Test suite:

1. ITI-41: Registrer stable dokument
2. ITI-61: Registrer on-demand dokument med referencer
   (tag kopi af databaserne)
3. ITI-41: Replace stable dokument
4. ITI-61: Replace on-demand dokument med referencer
5. ITI-18: Registry stored query (“find documents”) og ITI-43: retrieve document set
6. ITI-18: Registry stored query (“find documents by reference”)
7. ITI-57: Update metadata (deprecate dokument)

Der køres på en liste af cpr numre. Trin 1 og 2 opretter data og trin 3-7 arbejder herefter på disse data. Replace document og update metadata arbejder på konkrete dokumenter. Disse findes ved først at lave en ITI-18 søgning (som udelades af selve throughput beregningen).

3.1. Performance krav

Der findes ikke en officiel liste af krav til performance. Det vil derfor være hensigtsmæssigt at undersøge, hvordan performance er for det nuværende registry (og repository). Men vil herefter kunne vurdere, at man ialtfald ikke er dårligere stillet med det nye.

3.1.1. Krav:

1. Snitfladerne skal være mindst lige så hurtig som for den nuværende XDS registry (og repository)
2. Snitfladerne skal måles og svartiderne vurderes
3. Vurdering af, hvor stort et load, snitfladerne kan håndtere per time og per uge 

Add 3: Der måles en periode på 15 minutter og denne ganges op på time og uge basis.

3.1.2. Forudsætninger

Testen skal køres på en liste af cpr numre. Listen indeholder 100.000 forskellige numre. Udover disse cpr numre skal testen kunne afvikles selvstændigt og ikke være afhængig af andet test data.

Testen skal køre mod et registry og repository med en “passende” mængde baggrundsdata. Dette er et par millioner dokumenter af typerne stable og on-demand. Disse skabes i testens trin 1 og 2.

3.2. Baggrundsdata

Testens trin 3-6 forudsætter er der findes baggrundsdata at køre på. Trin 3 og 4 skal erstatte et eksisterende "approved" dokument, og trin 5 samt 6 skal fremsøge eksisterende dokumenter, og trin 7 skal deprecate eksisterende dokumenter.

Dette baggrundsdata skables i testens trin 1 og 2. Vurderes det, at disse 2 trin ikke har skabt nok baggrundsdata (et par millioner dokumenter) kan trin 1 og 2 gentages indtil, der er nok dokumenter. Da trin 7 deprecate i princippet fjerner sit eget data grundlag for at finde dokumenter at slette markere, skal der efter en deprecate oprettes et tilsvarende dokument.

3.3. Design af test

3.3.1. Overblik

Der findes følgende test planer til NXRG. 

Man kan i de forskellige test plan angive om der skal køres med eller uden dgws. Dette skal gøres nede på de enkelte samplers. Dette har betydning for, hvilken "path" der anvendes efter et givet endpoint.

Denne path kan også variere om kaldet er mod NXRG eller det eksisterende OpenText. Denne path justeres i kildekoden til test frameworket.

De test, hvor der udføres et "hjælpe" kald,  f.eks. når der laves en søgning inden erstatning af et dokument, da udelukkes "hjælpe" kaldet fra selve performance målingen ved at angive "ignore" i samplerens navn.

3.3.2. ITI-41 register

Dette er en registrering af et “stable” dokument.

Overvejelser omkring opsætningen

• Opret nye dokumenter
• Anvend forskellige cpr numre

Der er følgende muligheder for opsætning af testen:

Til testen anvendes følgende opsætning:

• CPR tilfældigt fra liste af numre
• Dokumenttypen APD
• De i sampler "OpretAftaleSampler.java" angivne værdier

3.3.3. ITI-61 register

Dette er en registrering af et “on-demand” dokument.

Overvejelser omkring opsætningen

• Opret nye dokumenter
• Anvend forskellige cpr numre

Der er følgende muligheder for opsætning af testen:

Til testen anvendes følgende opsætning:

• CPR tilfældigt fra liste af numre
• Dokumenttypen APD
• For referencer angives 5 for "generate document reference". Dette betyder, at dokumentet får 5 tildelte referencer i varianet af ef cpr nummer hashed
• Der anvendes derudover de i ovenstående skærmbillede angivne test data eller tilsvarende 

3.3.4. ITI41 replace og ITI-61 replace

Dette er som for ITI-41 register og ITI-61 register ovenfor. Forskellen er, at et eksisterende dokument skal erstattes. 

Overvejelser omkring opsætning:

• Anvend forskellige cpr numre og dokumenter

Til testen anvendes følgende opsætning:

• CPR tilfældigt fra liste af numre
• Dokumenterne fremsøges med et ITI-18 kald for et konkret cpr nummer og et af de fundne dokumenter replaces (Extract document identification from previous call)
• (Søgning udeledes af throughput beregningen ved at lave ordet "ignore" indgå i samplerens navn i opsætningen) 
• Der replaces med info som for "register"

3.3.5. ITI-18 registry stored query og ITI-43 retrieve document set

Dette er en fremsøgning af dokumenter og efterfølgende hent.

Overvejelser omkring opsætningen

• Søgnining imellem mange dokumenter

Der er følgende muligheder for opsætning af testen:

Fremsøgning:

Hent:

Til testen anvendes følgende opsætning:

• CPR tilfældigt fra liste af numre
• Der hentes kun stable documenter, da det efterfølgende iti-43 kald ellers vil fejle på on-demand dokumenterne
• Dato interval: skal ligge indenfor de datoer, hvor dokumenterne er registreret 
• Dokument typer, som hentes: APD 39289-4
• Der søges efter “approved” dokumenter (deprecate udelades)

3.3.6. ITI-18 registry stored query - by reference

Dette er en fremsøgning af dokumenter ud fra dokuments reference

Overvejelser omkring opsætningen

• Søgnining imellem mange dokumenter
• søgning med forskellige referencer, men ikke fra en "ekstern" liste

Der er følgende muligheder for opsætning af testen:

Til testen anvendes følgende opsætning:

• CPR tilfældigt fra liste af numre
• Der hentes kun on-demand documenter, da der kun er oprettet referencer på disse
• Dato interval: skal ligge indenfor de datoer, hvor dokumenterne er registreret 
• Dokument typer, som hentes: APD 39289-4
• Der søges efter “approved” dokumenter (deprecate udelades)
• For referencer angives 5 for "generate document reference". Dette betyder, at der tilfældig udvælges en reference - ud af 5 varianter over en cpr nummer hashed reference.

3.3.7. iti-57

Dette er en opdatering af til et eksisterende dokuments metadata - mere konkret dokument status bliver deprecated. 

Overvejelser omkring opsætningen

• Anvend forskellige cpr numre og dokumenter
• Man skal ikke "udhule" data grundlaget ved at deprecate alle dokumenter

Der er følgende muligheder for opsætning af testen:

Til testen anvendes følgende opsætning:

• CPR tilfældigt fra liste af numre
• Dokumenterne fremsøges med et ITI-18 kald for et konkret cpr nummer og on-demand typen, og et af de fundne dokumenters metadata opdateres
• Der deprecates som opdatering
• Der oprettes med et ITI-61 kald et nyt tilsvarende dokument.
• (Søgning og register) udelades af throughput beregningen ved at lave ordet "ignore" indgå i samplerens navn i opsætningen) 

3.4. Udførsel af test

3.4.1. Forberedelse

Testen hentes fra https://svn.nspop.dk/svn/components/performance/trunk i den revision, der er angivet nedenfor per release af NXRG.

Databasen klargøres; en tom database for både registry og repository

Der skal være en kørende version af NXRG, som er konfigureret med et tilhørende repository. Ligeledes skal dokumentdelings servicen være sat op foran NXRG.

host.properties skal være sat korrekt op jf. arosiis performance test framework. Repository unique id angives i REPOSITORY_UNIQUE_ID for iti-61 kaldene. Dvs for testplanerne nxrg_opret_iti61.template.jmx, nxrg_replace_iti61.template.jmx og nxrg_deprecate_iti57.template.jmx

I sourcekodens samplers findes metoden getPath(). Denne sti ned til det enkelte endpoint varierer efter, hvilken version af servicene som rammes og om der køres med eller uden DGWS. Det kan derfor være nødvendig at rette test sourcerne inden testen køres.

Eksempel for iti-18:

• Uden dgws:
  • kørsel mod open xds: /axis2/services/xdsregistryb
  • kørsel mod nuværende open text registry: /registry/services/xds-iti18
  • kørsel mod ny nxrg registry: /nxrg/iti18
• Med dgws:
  • /ddsregistry/service

3.4.2. Kørsel

Når databasen er på plads, DDS, NXRG og repository kørende og testen konfigureret, kan følgende køres. 

(distributionen 15min.template.jmx kører 15 minutter)

3.4.2.1. ITI-41 register

run_test.sh -h hosts.properties -p 9012 aftaler nxrg_opret 15min

3.4.2.2. ITI-61 register

run_test.sh -h hosts.properties -p 9012 ihe nxrg_opret_iti61 15min

3.4.2.3. ITI-41 replace

run_test.sh -h hosts.properties -p 9012 aftaler nxrg_erstat 15min

3.4.2.4. iti-61 replace

run_test.sh -h hosts.properties -p 9012 ihe nxrg_replace_iti61 15min

3.4.2.5. iti-18 og iti-43

run_test.sh -h hosts.properties -p 9012 aftaler nxrg_hent.template.jmx 15min

3.4.2.6. iti-18 og by reference

run_test.sh -h hosts.properties -p 9012 ihe nxrg_hent_iti18_by_reference 15min

3.4.2.7. iti-57 deprecate

run_test.sh -h hosts.properties -p 9012 ihe nxrg_deprecate_iti57 15min

3.5. Version

'* ' betyder hvilken som helst