Svareksponeringsservice XDS-Adaptere
Testvejledning
Indhold
1 Introduktion
1.1 Formål
1.2 Læsevejledning
1.3 Dokumenthistorik
1.4 Definitioner og referencer
2 Overblik over tests
2.1 Unittest
2.2 Integrationstest (til verifikation af funktionalitet)
2.3 Performancetests
2.4 Endurance-tests
3 Afviklede tests
3.1 Unittest
3.2 Integrationstest til verifikation af funktionalitet
3.2.1 Forberedelse
3.2.2 Setup
3.2.3 Testdata
3.2.4 Testdesign
3.2.5 Gennemførelse af integrationstests
4 Generering af code coverage-rapporter
4.1 Code coverage for unittests
4.1.1 Code coverage for unittests
4.1.2 Code coverage for unittests og integrationstests
Formålet med nærværende dokument er at beskrive de tests, som er udviklet og afviklet forud for release af Svareksponeringsservice XDS-adaptere. Desuden beskrives generering af code coverage-rapporter.
Dokumentet henvender sig til udviklere og testere. Læseren forventes at have kendskab til Java software udvikling, herunder unittesting, med anvendelse af Maven og Wildfly applikationsserver.
Version | Dato | Ansvarlig | Beskrivelse |
---|---|---|---|
1.0 | 20.09.2016 | Systematic | Initiel udgave |
Definition | Beskrivelse |
---|---|
DDS | Dokumentdelingsservice |
NSI | National Sundheds-IT |
NSP | Den nationale service platform (inden for sundheds-IT) |
XDS | Cross-Enterprise Document Sharing |
Alias | Beskrivelse |
---|---|
Udviklerguide | Guide til udviklere - Svareksponeringsservice XDS-adaptere, (SSE/11734/PHB/0045) |
Testrapport | Testrapport Svareksponeringsservice XDS-adaptere, (SSE/11734/TRP/0108) |
Konfiguration | Konfiguration af Svareksponeringsservice XDS-adaptere, (SSE/11734/NOT/0056) |
Følgende beskriver de forskellige tests og hvorvidt de er forberedt og gennemført ved release af Svareksponeringsservice XDS-adaptere.
Automatiserede unittests, der verificerer funktionalitet på klasse- eller komponentniveau, er tilgængelige jævnt over kodebasen og udføres, medmindre eksplicit frabedt, ved hvert byg af softwaren.
Automatiserede integrationstests, der verificerer både adfærd og brug af snitflader i setup, hvor Svareksponeringsservice XDS-adaptere er integreret med andre services, er tilgængelige. Integrationstestene kræver øvrige services for at kunne afvikles, hvilket er beskrevet i efterfølgende afsnit tillige med testdata og afvikling.
Performancetests verificerer at servicen performer med hensyn til svartider og/eller er stabil under et specifikt load, som i nogle tilfælde kan anvendes med samme mål som integrationstests.
Der er ikke forberedt eller kørt performancetest for Svareksponeringsservice XDS-adaptere.
Endurance-tests verificerer at servicen fungerer under længerevarende belastning og ikke lider under f.eks. memory leaks.
Der er ikke forberedt eller gennemført endurance-test for Svareksponeringsservice XDS-adaptere.
Følgende tests er afviklet som en del af komponentudviklingen og i forbindelse med release. Der henvises til \[Testrapport\] for fastholdelse af resultaterne fra gennemførte tests ifm. release. |
Unittests ligger i:
under de forskellige maven-artefakter, der indgår i Svareksponeringsservice XDS-adaptere. Resultatet af kørte tests opsummeres ved byg, beskrevet i \[Udviklerguide\]. |
Integrationstestene til Svareksponeringsservice XDS-adaptere verificerer, at der kan laves opslag af metadata og indhentning af dokument, når komponenterne i Svareksponeringsservice XDS-adaptere er integreret med Dokumentdelingsservicen og det backend-system, der leverer information om patienters prøvesvar.
Integrationstestene er baseret på en test-klient til Dokumentdelingsservicen skabt som automatiserede junit-tests, der anvender DDS-anvenderbiblioteket, der er en samling maven-artefakter skabt i regi af Dokumentdelingsservicen.
Følgende integrationstest demonstrerer adfærd ved timeout og utilgængelighed, hvilket kræver omkonfiguration inden kørsel (se herunder):
Der skal på Wildfly være deployeret:
\\ I stamdata skal testbruger være defineret som testperson med autorisationsnr. Testbrugeren skal være whitelistet til at anvende dokumentdelingsservicen, se afsnit 3.2.3. Der skal være etableret forbindelse til backend-systemet, hvilket potentielt indebærer oprettelse af laboratoriesvar i Laboratoriedatabanken. Dokumentdelingsservicen skal være konfigureret til at anvende Svareksponeringsservice XDS-adaptere, som beskrevet i \[Konfiguration\]. |
I Figur 1 er vist et setup til integrationstests baseret på en stub for Svareksponerneringsservicen.
Bemærk, at test-klientens tests fungerer uafhængigt af, hvordan de forskellige services er deployeret, hvorfor en vanlig opsætning af Dokumentdelingsservicen i NSP test1-miljø el. lign. kan anvendes.
Figur 1 Setup af services for afvikling af integrationstests for Svareksponeringsservice XDS-adaptere med lokalt deployerede adaptere og stub for Svareksponeringsservicen.
Under forudsætning af, at der findes testdata for testpatienter som beskrevet i afsnit 3.2.3, kan der alternativt køres integrationstests mod Svareksponeringsservice XDS Adaptere deployeret ved brug af Svareksponeringsservice hos Laboratoriedatabanken. Dette setup er vist i Figur 2.
Figur 2 Setup af services for afvikling af integrationstests for Svareksponeringsservice XDS-adaptere mod Svareksponeringsservice hos Laboratoriedatabanken.
Testklienten benytter et test-medarbejdercertifikat (MOCES) hentet fra et maven-artefakt etableret i regi af NSI, hvor organisationen bag er whitelistet til at benytte Dokumentdelingsservicen.
I testklienten er med property-fil konfigureret brug af følgende test-bruger, der er oprettet som testperson med autorisationsnummer i testmiljøets stamdata, f.eks. på NSP-miljø test1:
Læge Karl Hoffmann Svendsen, aut.reg.nr. NS362.
I testklienten er hardcoded anvendelse af følgende testpatienter:
Cpr-nummer for testpatient | Beskrivelse |
2512484916 | Cpr-nummer for testpatient med data i backend-systemet |
0101010101 | Cpr-nummer for testpatient uden data i backend-systemet |
Tabel 1 Id for testpatienter, der benyttes af tests.
Integrationstests, der verificerer Svareksponeringsservice XDS-adaptere ved at kalde Dokumentdelingsservicens snitflader, findes i filer under folderen integrationtest\src\test\java\dk\nsi\dds\projects\sxa\integrationtest.
Disse verificerer følgende (for detaljer henvises til filer under nævnte folder) ved positive tests:
Integrationstestene verificerer følgende (for detaljer henvises til filer under nævnte folder) ved negative tests:
Inden kørsel af integrationstests skal etableres en property-fil, der beskriver endpoints for eksterne systemer mm. Som skabelon anvendes property-filen:
Denne kan kopieres og tilpasses til aktuelt miljø. Efterfølgende Maven-kommandoer gør brug af tilpassede property-fil gennem argumentet:
-Dtestclient-property-file=<sti til tilpasset testclient.properties>
Er argumentet ikke anført benytter Maven-scripts den oprindelige property-fil.
Integrationstests gennemføres ved at udføre maven-kommando:
mvn verify –Pexternal-test \
-Dtestclient-property-file=<sti til tilpasset testclient.properties>
Integrationstestene understøttes kun ved brug af Svareksponeringsservice stubben "labreportservicestub".
Bemærk, at visse integrationstests kræver konfigurationsændringer og derfor er sat til ignored. Disse kan, efter konfigurationsændring som beskrevet i deres javadoc, køres selvstændigt ved at udkommentere ignore og tilføje argument –Dit.test=<testklasse-navn> til ovenstående maven-kommando.
Code coverage kontrolleres ved brug af Cobertura, som foreslået af NSP Husregler (for leverandører). Code coverage-rapporter fra et release er fastholdt i tilhørende \[Testrapport\]. |
Code coverage analyse er foretaget i projektet med anvendelse af Maven Cobertura plugin.
Code coverage-rapport omfattende alene unittests genereres ved at gennemføre følgende trin:
mvn clean site cobertura:cobertura
En samlet code coverage-rapport omfattende både unittests og integrationstests kan genereres ved forberedelse og gennemførsel af trin beskrevet i det efterfølgende.
Cobertura skal installeres på WildFly og Ant installeres mhp. anvendelse ved fletning af code coverage-rapporter fra unittest og integrationstests.
De anvendte versioner er:
Trin:
I Ant's lib folder bør følgende jars være tilgængelige
Jar | Fremskaffelse |
---|---|
asm-5.0.1.jar | Indeholdende i Cobertura-2.1.1-bin-tar |
asm-analysis-5.0.1.jar | Indeholdende i Cobertura-2.1.1-bin-tar |
asm-commons-5.0.1.jar | Indeholdende i Cobertura-2.1.1-bin-tar |
asm-tree-5.0.1.jar | Indeholdende i Cobertura-2.1.1-bin-tar |
asm-util-5.0.1.jar | Indeholdende i Cobertura-2.1.1-bin-tar |
cobertura-2.1.1.jar | Indeholdende i Cobertura-2.1.1-bin-tar |
commons-lang3-3.3.2.jar | Indeholdende i Cobertura-2.1.1-bin-tar |
oro-2.0.8.jar | Indeholdende i Cobertura-2.1.1-bin-tar |
slf4j-api-1.7.5.jar | Indeholdende i Cobertura-2.1.1-bin-tar |
slf4j-log4j12-1.6.4.jar | Bør være i lokal m2 folder |
log4j-1.2.16.jar | Bør være i lokal m2 folder |
Følgende Cobertura afhængigheder kopieres fra cobertura-2.1.1-bin.tar.gz til <wildfly folder>/modules/net/sourceforge/cobertura/main
Jar | Destination |
---|---|
<arkiv>/cobertura-2.1.1.jar | <modul-main>/ |
<arkiv>/lib/asm-tree-5.0.1.jar | <modul-main>/lib/ |
<arkiv>/lib/asm-commons-5.0.1.jar | <modul-main>/lib/ |
<arkiv>/lib/asm-util-5.0.1.jar | <modul-main>/lib/ |
<arkiv>/lib/asm-analysis-5.0.1.jar | <modul-main>/lib/ |
<arkiv>/lib/oro-2.0.8.jar | <modul-main>/lib/ |
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="net.sourceforge.cobertura">
<resources>
<resource-root path="."/>
<resource-root path="cobertura-2.1.1.jar"/>
<resource-root path="lib/asm-tree-5.0.1.jar"/>
<resource-root path="lib/asm-commons-5.0.1.jar"/>
<resource-root path="lib/asm-util-5.0.1.jar"/>
<resource-root path="lib/asm-analysis-5.0.1.jar"/>
<resource-root path="lib/oro-2.0.8.jar"/>
</resources>
<dependencies>
<module name="asm.asm" />
<module name="javax.servlet.api" />
<module name="org.slf4j" />
</dependencies>
</module>
net.sourceforge.cobertura.datafile=<sti>/cobertura.ser
For at få Cobertura til at skrive coverage af integrationstests, er der to muligheder:
Metode | Installation og brug |
---|---|
coberturaFlush.war servicen |
|
Efter ændring deployeres coberturaFlush.war og servicen udstiller "<host>/coberturaFlush/flushCobertura". Kald til denne service ved f.eks. Curl får Cobertura til at skrive coverage filen. (Se trin 3.3).|
Genstart af WildFly |
|
Code coverage-rapport omfattende både unittests og integrationstests genereres ved at gennemføre følgende trin:
mvn clean install -Dcobertura-build \
-Pdeploy-to-appserver \
-Denvironment-property-file=<sti til tilpasset environment.properties>
Bemærk, at argumentet –Pdeploy-to-appserver aktiverer en maven-profil, der kopierer ear/war-filer til WildFly deployment folder vha. properties. Som alternativ til dette argument kan ear/war-filer deployeres manuelt.
mvn verify –Pexternal-test __
-Denvironment-property-file=<sti til tilpasset environment.properties> \
-Dtestclient-property-file=<sti til tilpasset testclient.properties>
cd cobertura/target/coberturaReporting-coberturaReporting
ant –f cobertura.xml create-report