Introduktion

Formål

Formålet med dette dokument er at beskrive de tests, som er udviklet og afviklet forud for release af DDS Registry.

Følgende typer af test bruges indgår i udviklingsarbejdet:

• Unittests, der verificerer, at de individuelle enheder i kildekoden virker efter hensigten, herunder måling af code coverage.

• Integrationstest, der verificerer at de individuelle enheder kan integreres og arbejde sammen, til verifikation af funktion og deployment.

• Performancetest, der verificerer at servicen performer med hensyn til svartider og er stabil under et specifikt load, som i nogle tilfælde kan anvendes med samme mål som integrationstests.

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

For de typer af tests og det også beskrevet i hvilket omfang der er særlige krav til testdata, og hvorledes etablerede testdata kan vedligeholdes.

Læsevejledning

Dokumentet henvender sig til udviklere og testere. Læseren forventes at have kendskab til Java software udvikling, herunder unittesting, med anvendelse af Maven, JBoss applikationsserver og MySQL.

Dokumenthistorik

Definitioner og referencer

Afviklede komponenttest

Følgende tests er afviklet som en del af komponent udviklingen. Der henvises i øvrigt til [UdviklerGuide] for udførselsvejledning og [TestRapport] for resultat.

Unittest til Code Coverage

DDS Registry\s unittests ligger i:

• dds\ddsregistry\application\src\test\java\dk\nsi\ddsregistry\adhocquerywrapper\AdhocQueryRequestWrapperTest.java

• dds\ddsregistry\application\src\test\java\dk\nsi\ddsregistry\adhocquerywrapper\AdhocQueryResponseWrapperTest.java

• dds\ddsregistry\application\src\test\java\dk\nsi\ddsregistry\impl\DDSRegistryLogicTest.java

• dds\common\src\test\java\dk\nsi\ddsservices\invocation\treatmentrelation\TreatmentRelationInvokerTest.java

• dds\common\src\test\java\dk\nsi\ddsservices\lookup\authorisationcode\AuthorisationCodeCheckerTest.java

• dds\common\src\test\java\dk\nsi\ddsservices\ws\impl\UserCheckTest.java

AdhocQueryRequestWrapperTest verificerer at udtræk af patient id fra AdhocQueryRequest er korrekt.

AdhocQueryResponseWrapperTest tester metoder på AdhocQueryResponseWrapper til filtrering af AdhocQueryResponse ud fra samtykker.

DDSRegistryLogicTest tester den implementerede forretningslogik i DDS Registry, fejlhåndtering og delvist tilgængelighed af de backend services DDS Registry bruger.

TreatmentRelationInvokerTest tester integrationen mod behandlingsrelationsservicen.

AuthorisationCodeCheckerTest tester rettighedsstyring i forhold til autorisationstabellen, som i testen er en in-memory-database.

UserCheckTest tester valideringens- og autorisationslogikken til rettighedsstyring ifm. HSUID-roller.

Integrationstest til verifikation af funktionalitet

Integrationstestene til DDS Registry er baseret på en genereret klient til den allerede eksisterende DocumentRegistry service.

DDS Registry har en integrationstest, der afvikles automatisk:

• dds\ddsregistry\integrationtest\src\test\java\dk\nsi\ddsregistry\ws\DDSRegistryIT.java

• dds\ddsregistry\integrationtest\src\test\java\dk\nsi\ddsregistry\ws\DDSRegistryRegisterIT.java

Tester DDS Registry via DDS Registry web service interfacet. Opslag gennemføres under anvendelse af Registry Stored Query, der i testnavne er forkortet regSQ.

Derudover findes der integrationstests beskrevet i afsnit 2.2.2 og 2.2.3, der kræver specielle forudsætning og derfor ikke igangsættes automatisk.

Testdata

Keystores benyttes i forbindelse med integrationstestene både af test-drivere og af services deployeret til JBoss.

Integrationstestenes test-drivere benytter keystores validVocesVault.jks, expiredVocesVault.jks og validMocesVault.jks, der udtrækkes automatisk fra maven-artefaktet remote-test-resources (dk.nsi.dgws) ved kørsel af integrationstest.

Services deployeret til JBoss (fx DDS Registry) benytter validVocesVault.jks, der ved deployering ligeledes udtrækkes fra remote-test-resources.

Integrationstestene er afhængige af pre-installeret testdata for:

• Samtykker

• Whitelist

• Stamdata (SOR-data og autorisationsregister-data)

Når integrationstestene afvikles på miljø uden stamdata bliver alle ovennævnte testdata installeret, når data-sources etableres (se [UdviklerGuide]).

Når integrationstestene afvikles på NSP (hvor stamdata allerede er etableret), bliver samtykker og whitelist testdata installeret. Dette sker tillige automatisk i forbindelse med etablering af data-sources (se [UdviklerGuide]).

Integrationstest med utilgængelig DDS Registry

Under integrationstests er der følgende fil, der ikke afvikles automatisk:

• dds\ddsregistry\integrationtest\src\test\java\dk\nsi\ddsregistry\ws\DDSRegistryDisabled.java

Testen validerer at den korrekte fejlmeddelelse bliver returneret, når IHE Registry er nede. Inden afvikling af testen skal IHE Registry gøres utilgængelig, fx ved at konfigurere en invalid service URL i DDSRegistry-konfigurationsfilen. Dette er beskrevet i filen HowToRun-DDSRegistryDisabled.txt.

Testen afvikles manuelt med følgende kommando:

mvn -Dit.test=DDSRegistryDisabled verify –Pexternal-test

Integrationstest med HSStub

Under integrationstests er der følgende fil, der ikke afvikles automatisk:

• dds\ddsregistry\integrationtest\src\test\java\dk\nsi\ddsregistry\ws\DDSRegistryTestRequiringHSStub.java

Testen validerer at DDSRegistry kan håndtere voluminøse svar fra IHE Registry. Inden afvikling af testen skal:

1. IHE Registry erstattes med HSStub i DDSRegistry-konfigurationsfilen. I DDSRegistry.properties skal documentregistry.wsdl.location, der peger på hsbus/HS.IHE.XDSb.Registry.Services.cls udkommenteres og erstattes af tilsvarende indgang, der peger på DocumentRegistry_Service/HSStub.

2. HSStub være deployeret og startet.

Testen afvikles manuelt med følgende kommando:

mvn -Dit.test=DDSRegistryTestRequiringHSStub verify –Pexternal-test

Performancetests

Performancetesten af baseret på requests fra integrationstesten. Ved integrationstesten gemmes to DDS Registry soap requests, per default under c:\dds. Dette kan konfigureres vha. environment property filen, som findes under dds\environment.properties, ved at sætte property’en soaprequest.log.dir.

Herefter skal databasen på test target (fx NIAB) initieres hvilket gøres fra performance folderen med:

mvn initialize -Pperf-setup

Selve performancetestene er lavet i JMeter og er gemt under:

• performance\src\main\test\resources\jmeter\regSQHealthcareProfessionalDataSpecNegConsentOrgHavingDataSpecPosConsentAndOnBehalfOfPerf.jmx

• performance\src\main\test\resources\jmeter\regSQHealthcareProfessionalPerformingConsentOverridePerf.jmx

Hvis man har valgt at sætte soaprequest.log.dir property’en til noget andet end c:\dds skal filnavet i jmx-filen ligeledes ændres. Dette gøres i JMeter ved at redigere ’Filename’ under ’DDSRegistry’ > Loop Controller > SOAP/XML-RPC Request”.

Verificer at test target URL er konfigureret korrekt (hostname:port) i JMeter SOAP/XML dialog.

Der bør udføres check fra JMeter at request til test target fungerer korrekt inden den automatiske test gennemføres og der genereres chronos rapporter.

Performance tests gennemføres fra en workstation med adgang til test target med kommandoen:

mvn verify –Pddsregistry-data chronos-report:report
mvn verify –Pddsregistry-consentoverride chronos-report:report

Chronos HTML reporter findes under performance\target\site (folderne css og images medtages).

Efter at havde kørt performancetesten kan load data fjernes fra databasen på test target med.

mvn initialize -Pperf-teardown

Testdata

Test dataene bliver skabt af DDSPerfTestSetup.sql sql-scriptet som ligger under performance\src\main\test\resources\sql\DDSPerfTestSetup.sql

Endurancetest

Der er ikke kørt nogen separat endurance test på DDS Registry.

Testdata

Der er ingen særlige testdata eller krav til testdata for disse tests.