Overblik

Dette dokument beskriver en testvejledning for Det Fælles Stamkort 1.5-servicen. Det forudsættes at projektet er bygget og installeret, og med denne vejledning kan man således afvikle integrations- og performancetests og derved kontrollere robustheden.

Ændringslog

Integrationstests

Integrationstest skal afvikles mod den deployede komponent med test-opsætning.

Selve integrationstesten består af et kald til OnDemand webservicen.

Når servicens er installeret og deployet, kan korrekt deployment verificeres ved at køre integrationstestene. Dette gøres ved at anvende følgende Maven-kommando, som aktiverer Maven-profilen extITs og specificerer adressen på det specificerede miljø:

mvn verify -pl fsk-test -PextITs -DFSK_TEST_HOST=<host> -DFSK_TEST_PORT=<port> -DFSK_TEST_DOCID=<docid>

I ovenstående kommando skal <host> erstattes med adressen på det miljøet, <port> med portnummeret, servicen svarer på (typisk 8080), og <docid> med et dokument-id, som findes i RegistryIndex-tabellen i det pågælende eksterne testmiljøs FSK database.

Bemærk at dette kræver, at projektet er fuldt bygget, for at lokale dependencies er på plads.

BEMÆRK: For at køre integrationstests lokalt, skal man have BTR, LTR, ODR og SKR kørende lokalt. Projekterne BTR, ODR og SKR indeholder docker-compose setups til dette formål. Hvis man har disse projekter tjekket ud, kan man starte de nødvendige services op som følger.

1. Fra roden af fsk-projektet:

docker-compose -f compose/development/docker-compose.yml up -- build

Bemærk: Det kan tage op mod et minut før containeren er klar. De nødvendige databaser bliver oprettet automatisk. Bemærk at projektet skal bygges før ovenstående kommando fungerer, dette gøres med følgende kommando, ligeledes fra projektroden:

mvn clean install -DskipTests=true

2. Fra roden af btr-projektet:

docker-compose -f compose/fsk-integrationtest/docker-compose.yml up

3. Fra roden af odr-projektet:

docker-compose -f compose/fsk-integrationtest/docker-compose.yml up

4. Fra roden af skr-projektet:

docker-compose -f compose/fsk-integrationtest/docker-compose.yml up

Når alt er oppe, kan integrationstests afvikles lokalt med følgende kommando:

mvn verify -pl fsk-test -PextITs

Hvis man er uheldig og kommer til at afvikle testen med f.eks. Java 11 får man en fejl om at attributten soapenv:mustUnderstand ikke må være der. Det kan få en til og tro at det er FSK og eller testen der er noget i vejen med. Problemet er dog højest sandsynligt at man ikke anvender Java 8 når man afvikler testen.

Codecoverage

Efter afvikling af unittests genereres en testrapport med Maven-plugin’et JaCoCo. Rapporten kan ses ved at åbne følgende fil i en browser:

fsk-service/target/site/jacoco/index.html

Dette gælder for selve fsk-service og dets funktionalitet, som refereres til modul: fsk. 

I aktuelle version af fsk-service er codecoverage 80%. Der henvises til JaCoCo testrapporten for yderligere information vedr. coverage.

Verifikation og fejlfinding

Nedenstående beskrivelse kan benyttes hvis der er behov for mere detaljeret verifikation og fejlfinding på et FSK-miljø.

Der er følgende integrationer i FSK:

1. Replikering af NSP stamdata til tabellerne YderregisterPerson_v3, Yderregister_v3 og v2_Person.
2. Registrering af dokument-metadata i DDS registry baseret på CPR-data fra v2_Person.
3. Kald til FSKs DocumentProviderWS fra DDS, hvilket medfører kald til SCES, SKR, LTR/BTR og ODR

De forskellige integrationer kan verificeres på følgende måde:

1. Hvis replikeringen af stamdata har været succesfuld, bør der være data i de 3 nævnte tabeller. I produktion findes nedenstående tabelstørrelser (på testmiljøer findes der kun en brøkdel):

YderregisterPerson_v3 ca. 21.000
Yderregister_v3: ca. 63.000
v2_Person: 14-15 mio

2. FSK opdaterer dokumentdelingsservicens registry, så der findes metadata for personer der er markeret som levende i v2_Person. Når der registreres metadata for et CPR-nummer, vil der opstå en ny række i FSK-tabellen RegistryIndex, som indeholder en registrering af FSKs dokumentId og CPR-nummer. Når synkroniseringen er færdigkørt, bør antallet af rækker i RegistryIndex matche antal aktive personer i v2_Person (med status 01 og ValidFrom < now() < ValidFrom).

3. Når FSK har registreret metadata for et CPR-nummer i DDS, kan FSKs on-demand service kaldes gennem DDS. Dette gøres nemmest via testklasse der ligger her i projektet:

fsk.service/src/test/java/dk/stamkort/integrations/dds/DDSIntegrationTest.java

I testklassen indsættes værdierne fra en tilfældig række i tabellen RegistryIndex i variablerne personIdentifier og fskDocumentId. Testen benytter konfiguration fra fsk-service/src/test/resources/testclient.properties, som skal tilrettes hvis der ikke er tale om test1-miljøet (se evt. afsnit 2.2 her: https://www.nspop.dk/pages/viewpage.action?pageId=32126754). Endvidere skal man redigere værdien af "dds.repository.unique.id" i fsk/src/test/resources/application.properties, så det matcher miljøet (se evt. installationsvejledningen mht. hvilke værdier der hører til hvilke miljøer).

En kørsel af callDDS-testen bør resultere i logning af følgende i testklassen:

Errors: 0
Warnings: 0
Retrieved documents: 1
Unreachable documents: 0
Returned document: <?xml version="1.0" encoding="UTF-8" standalone="yes"?><POCD_MT000040.ClinicalDocument moodCode="EVN" classCode="DOCCLIN" xmlns="urn:hl7-org:v3" xmlns:ns2="urn:hl7-org:sdtc" xmlns:ns3="urn:hl7-org:fsk">...</POCD_MT000040.ClinicalDocument>

Hvis der skulle opstå en fejl i FSK ifm. generering af dokumentet, vil det resultere i logning af "Unreachable documents: 1". I den situation er det nødvendigt at inspicere FSKs logfiler for at finde årsagen til fejlen.