1. Anchor
   _Toc327542696 _Toc327542696

Anchor
_Toc327543205 _Toc327543205

Anchor
_Toc462245117 _Toc462245117

Introduktion

Anchor
_Toc316542421 _Toc316542421

Anchor
_Ref317083052 _Ref317083052

Anchor
_Toc327543206 _Toc327543206

Anchor
_Toc462245118 _Toc462245118

Formål

Anchor
_Toc327543208 _Toc327543208

Anchor
_Toc462245119 _Toc462245119

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 og Wildfly applikationsserver.

Anchor
_Toc317831244 _Toc317831244

Anchor
_Toc317839917 _Toc317839917

Anchor
_Toc327543209 _Toc327543209

Anchor
_Toc462245120 _Toc462245120

Dokumenthistorik

Anchor
_Toc327543210 _Toc327543210

Anchor
_Toc462245121 _Toc462245121

Definitioner og referencer

Anchor
_Toc327543211 _Toc327543211

Anchor
_Toc462245122 _Toc462245122

Overblik over tests

Følgende beskriver de forskellige tests og hvorvidt de er forberedt og gennemført ved release af Svareksponeringsservice XDS-adaptere.

Anchor
_Toc327543212 _Toc327543212

Anchor
_Toc462245123 _Toc462245123

Unittest

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.

Anchor
_Toc327543213 _Toc327543213

Anchor
_Toc462245124 _Toc462245124

Integrationstest (til verifikation af funktionalitet)

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.

Anchor
_Toc327543215 _Toc327543215

Anchor
_Toc462245125 _Toc462245125

Performancetests

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.

Anchor
_Toc327543217 _Toc327543217

Anchor
_Toc462245126 _Toc462245126

Endurance-tests

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.

Anchor
_Toc462245127 _Toc462245127

Afviklede tests

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.

Anchor
_Toc462245128 _Toc462245128

Unittest

Unittests ligger i:

• *\src\test\java*

under de forskellige maven-artefakter, der indgår i Svareksponeringsservice XDS-adaptere. Resultatet af kørte tests opsummeres ved byg, beskrevet i \[Udviklerguide\].

Anchor
_Ref416952058 _Ref416952058

Anchor
_Toc462245129 _Toc462245129

Integrationstest til verifikation af funktionalitet

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

• integrationtest\src\test\java\dk\nsi\dds\projects\sxa\integrationtest\SxaConfigurationChangeIT.java

Anchor
_Toc462245130 _Toc462245130

Forberedelse

Der skal på Wildfly være deployeret:

• Dokumentdelingsservices (og dennes afhængigheder til øvrige services, se herunder).
• Svareksponeringsservice XDS-adaptere

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\].

Anchor
_Toc462245131 _Toc462245131

Setup

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.

Anchor
_Ref416957589 _Ref416957589

Anchor
_Toc462245132 _Toc462245132

Testdata

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:

Tabel 1 Id for testpatienter, der benyttes af tests.

Anchor
_Toc462245133 _Toc462245133

Testdesign

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:

• At der returneres dokumentmetadata for Svareksponeringsservice XDS-adaptere ved opslag på testpatient på Dokumentdelingsservicen ved anvendelse af søgeparametre specifikke for laboratoriesvarsdokumenter
• At fremfundne dokumentmetadata for laboratoriesvarsdokument afspejler kombinationer af start- og stop-tidspunkter i søgeparametre
• At der returneres laboratoriesvarsdokument med tomt resultat-afsnit ved indhentning af dokument på Dokumentdelingsservicen for testpatient uden data i backend-systemet
• At der returneres laboratoriesvarsdokument indeholdende laboratoriesvar ved indhentning af dokument på Dokumentdelingsservicen for testpatient med data i backend-systemet
• At der returneres laboratoriesvarsdokument med tomt laboratoriesvars-afsnit ved indhentning af dokument på Dokumentdelingsservicen for testpatient med data i backend-systemet, når dette sker baseret på søgning med periode, hvor der ikke er taget prøver.

Integrationstestene verificerer følgende (for detaljer henvises til filer under nævnte folder) ved negative tests:

• At der ikke returneres dokumentmetadata for laboratoriesvarsdokument, når opslag på testpatient på Dokumentdelingsservicen sker uden anvendelse af søgeparametre specifikke for laboratoriesvarsdokument.

Anchor
_Ref449955886 _Ref449955886

Anchor
_Toc462245134 _Toc462245134

Gennemførelse af integrationstests

Inden kørsel af integrationstests skal etableres en property-fil, der beskriver endpoints for eksterne systemer mm. Som skabelon anvendes property-filen:

• <component base>/integrationtest\src\test\resources\testclient.properties

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 fra integrationtest-directory:

cd integrationtest
mvn verify –Pexternal-test -Dtestclient-property-file=<sti til tilpasset testclient.properties>

Eksempel:

cd integrationtest
mvn verify -Pexternal-test -Dtestclient-property-file=./src/test/resources/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.

Anchor
_Toc462245135 _Toc462245135

Generering af code coverage-rapporter

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\].

Anchor
_Toc462245136 _Toc462245136

Code coverage for unittests

Code coverage analyse er foretaget i projektet med anvendelse af Maven Cobertura plugin.

Anchor
_Toc417550117 _Toc417550117

Anchor
_Toc434997540 _Toc434997540

Anchor
_Toc435777515 _Toc435777515

Anchor
_Toc449964616 _Toc449964616

Anchor
_Toc462245137 _Toc462245137

Code coverage for unittests

Code coverage-rapport omfattende alene unittests genereres ved at gennemføre følgende trin:

• I kommandoprompt i SXA hovedfolder (folderen med parent pom) udføres:

mvn clean site cobertura:cobertura

• Genereret code coverage-rapport kan nu læses i folderen target/site/cobertura

Anchor
_Toc417550118 _Toc417550118

Anchor
_Toc434997541 _Toc434997541

Anchor
_Toc435777516 _Toc435777516

Anchor
_Toc449964617 _Toc449964617

Anchor
_Toc462245138 _Toc462245138

Code coverage for unittests og integrationstests

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.

Anchor
_Toc417550119 _Toc417550119

Forberedelse

Cobertura skal installeres på WildFly og Ant installeres mhp. anvendelse ved fletning af code coverage-rapporter fra unittest og integrationstests.
De anvendte versioner er:

• Cobertura 2.1.1
• Ant 1.9.4

Trin:

1. Cobertura etableres, ved enten:
   1. Download fra fx sourceforge (https://sourceforge.net/projects/cobertura/) og udpakning
   2. Kildekode hentes fra https://github.com/cobertura/cobertura/releases og bygges
2. Ant installeres
   1. Download fra http://archive.apache.org/dist/ant/binaries/apache-ant-1.9.4-bin.tar.gz

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

3. Installation af Cobertura modul på WildFly:

   1. 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/

   2. En module.xml fil skabes i samme main mappe med følgende indhold:

      Code Block

      <?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>

   3. Default udskrives coveragefilen (cobertura.ser) i <wildfly folder>/bin mappen. Ønskes filen udskrevet til en anden mappe skabes filen cobertura.properties i main mappen med indeholdet:

      Code Block
      net.sourceforge.cobertura.datafile=<sti>/cobertura.ser

   4. For at få Cobertura til at skrive coverage af integrationstests, er der to muligheder:

      Metode	Installation og brug
      coberturaFlush.war servicen	coberturaFlush.war er at finde i Cobertura-2.1.1-bin-tar Før kopiering til <WildFly>/standalone/deployments skal følgende linje tilføjes til coberturaFlush.war/META-INF/MANIFEST.MF: Code Block Dependencies: net.sourceforge.cobertura 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	Cobertura skriver automatisk coverage fil ved genstart af WildFly Denne mulighed kræver følgende ændring i <wildfly folder>/bin/standalone.conf med tilføjelse af: Code Block JAVA_OPTS="$JAVA_OPTS -Djboss.shutdown.forceHalt=false"

      Bemærk at når WildFly startes med instrumenteret kode, da startes "optagelse" af code coverage. Ved kald til coberturaFlush servicen skabes et billede af hvordan coverage ser ud nu. Dette billede skrives til <wildfly>/bin/cobertura.ser, hvor filen bliver additivt opdateret, hvis filen findes i forvejen, eller skabes, hvis den ikke findes. "Optagelse" af code coverage bliver først reset ved genstart af WildFly og fjernelse af <wildfly>/bin/cobertura.ser.

   5. Genstart af WildFly

Anchor
_Toc417550120 _Toc417550120

Gennemførelse

Code coverage-rapport omfattende både unittests og integrationstests genereres ved at gennemføre følgende trin:

1. Kontroller, at wildfly bruger-account kan skrive cobertura.ser filen i output folderen (Standard <wildfly>/bin/cobertura.ser eller bestemmes i cobertura.properties)
2. Kontroller, at stien til cobertura.ser er korrekt i filen cobertura/src/main/coberturaScripts/cobertura.properties under SXA-projektets hovedfolder.

3. Coberturas instrumentering af koden sker ved udførsel af følgende i kommandoprompt i SXA-projektets hovedfolder (folderen med parent pom):

   Code Block
   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.

4. Gen-deployer SXA-projektets services på WildFly

5. I samme folder udføres integrationstestene ved:

   Code Block
   mvn verify –Pexternal-test __ -Denvironment-property-file=<sti til tilpasset environment.properties> \ -Dtestclient-property-file=<sti til tilpasset testclient.properties>

6. Afslutning af coberturas optagelse gennemføres ved enten:
   1. Shutdown af WildFly, eller
   2. At åbne siden http://<host:port>/coberturaFlush/flushCobertura (fx via curl eller i browser. Bemærk at dette forudsætter at filen coberturaFlush.war blev kopieret og deployeret)

7. Flet code coverage-rapporter ved i kommandoprompt i SXA hovedfolder at udføre:

   Code Block
   cd cobertura/target/coberturaReporting-coberturaReporting ant –f cobertura.xml create-report

8. Genereret code coverage-rapport kan nu læses i folderen cobertura/target/coberturaReporting-coberturaReporting/report