Page History
Indhold
Table of Contents |
---|
Indledning
Leverancen indeholder unit tests, integrationstest og endurancetest.
Unittests afvikles som en del af byggeprocessen, mens integrationstesten afvikles mod den deployede komponent. Begge disse tests afvikles med maven.
Endurancetesten afvikles med jmeter mod den deployede komponent.
Indeværende dokument indeholder beskrivelse af, hvordan disse tests afvikles. Resultatet af endurancetesten er beskrevet i særskilt dokument.
Læsevejledning
Læseren forventes at have kendskab til National Sundheds-IT's platform NSP, samt generelt kendskab til WildFly applikation server, MariaDB og java.
Dokumenthistorik
Version | Dato | Ansvarlig | Beskrivelse |
1.2 | 25-09-2018 | Openminds | Yderligere specifikation som følge af ny borgerservice og Kafka |
1.1 | 07-09-2017 | Openminds | Tilføjelse af yderligere integrationtests |
1.0 | 15-06-2017 | Aage Nielsen |
Definitioner og forkortelser
Definition | Beskrivelse |
NSP | Den nationale service platform (inden for sundheds-IT) |
Unit tests
Unit tests bliver afviklet som en del af bygget, med mindre man eksplicit angivet, at det ikke ønskes.
Kør 'mvn clean install' eller 'mvn clean test'
Coverage report
Cobertura benyttes til – via maven – at danne en coverage rapport:
|
Rapporten kan også findes i code/target/staging.
Bemærkninger
Det er et krav, at der skal være en coverage på 80 %. Dog kan fx genereret kode afvige fra dette.
Nedenfor er beskrevet, hvilke pakker, der vurderes ikke at leve op til coverage kravet.
Følgende pakker indeholder genereret kode eller 3. part:
- dk.medcom.dgws.*
- oasis.*
- org.*
- dk.sundhedsdatastyrelsen.minlog.xml_schema.*
Derudover kode uden forretningslogik
Integrationstest
Der findes en række forskellige integrationstests og for alle gælder det at de validere at komponenterne er deployet korrekt og understøtter følgende use cases:
- Registrering af en log hændelse (kræver Kafka er til rådighed)
- Opslag på log hændelser via CPR
Der findes en række test classer som kan benyttes i forskellige sammenhæng. Vær opmærksom på at der findes 2 moduler som anvendes med test af integration for øje.
- shared-test - integrationtest af registrering og medhjælp opslag
- shared-test-idws - integrationstest af borger opslag
Nedenstående er en liste over shared-test:
IntegrationTest | Standard integrationstest. Kontrollere at miljøerne er kørende, kalder Registration og derefter Lookup |
RunMultipleIntegrationTests | Afvikler alle tests baseret på plain xml-filer – se : |
ExternalLookupTest | Afvikler enkeltstående test – request findes i lookup-snippet.xml |
ExternalRegistrationTest | Afvikler enkeltstående test – request findes i registration-snippet.xml |
XMLValidator | Validerer korrekt xml fra filen xml-tovalidate.xml |
shared-test-idws består af:
IDWSTestClient | Standard integrationstest. Kontrollere at miljøerne er kørende, kalder først op til STS og derefter Lookupid |
IDWSHelper | Validerer xml signatur fra fil |
Afvikling
Integrationstesten kan afvikles fra en kommandolinje mod komponenten på en kørende JBoss server. Testen kan enten afvikles med et id kort som parameter eller selv danne et id kort ved at kalde test STS.
Det er muligt at læse konfigurationen fra en fil eller med parametre til kommandolinjen:
|
Runtime konfigurationen overstyrer konfiguration i bygget. Dette gælder for alle integrationstests.
Følgende konfigurationer er til rådighed:
minlog2.endpoint.registration.url | Angivelse af MinLog2 servicens endpoint, fx http://localhost:8080/minlog2-registration/RegisterService |
minlog2.endpoint.lookup.url | Angivelse af MinLog2 servicens endpoint, fx http://localhost:8080/minlog2-lookup/LookupService |
idcard.from.file | Angiver, hvorvidt id kortet skal læses fra en fil. |
sts.endpoint.url | Angivelse af STS endpoint, fx http://test2.ekstern-test.nspop.dk:8080/sts/services/SecurityTokenService
|
idcard.path | Absolut sti til id kort. |
db.url | Database url til en MariaDB database. Anvendes af "RunMultipleIntegrationTests" til at slette alle logentries markeret med Systemname='Integrationtest' |
Hvis id kortet skal dannes af testen skal følgende være opfyldt:
- Adgang til security token service
- At certifikatet Lis_Rasmussen_Laege.jks.jks, har password Test1234og er tilknyttet CVR 25450442
Integrationtest til Lookupid (shared-test-idws)
Modulet shared/shared-test-idws indeholder en klient IDWSTestClient. En integrationtest der kontrollere at miljøerne er kørende og kalder Lookupid. Denne client kræver at IntegrationTest er blevet afviklet mindst en gang mod det ønskede miljø da request indeholder opslag på CPR "1005781993".
Ingen konfiguration er nødvendig. Afvikling sker fra kommandolinjen som følger:
mvn exec:java |
Konfiguration foretages i src/main/resources/client.properties.
org.apache.ws.security.crypto.merlin.keystore.type=jks |
"tofile" will save the request to file - (IDWS-request-output.xml). Vær opmærksom på sts-endpoint og lookup-endpoint. Ændringer til lookup-endpoint skal også ændres i minlog2-lookupid.wsdl filen
...
<wsdl:service name="LookupidService">
<wsdl:port name="LookupidServicePort" binding="tns:LookupidSoapBinding">
<soap:address location="http://localhost:8081/minlog2-lookupid/LookupidService" />
</wsdl:port>
</wsdl:service>
...
Performance- og endurancetest
Der henvises til Performancetest dokumentet.
Dannelse af ID kort (wsse header)
Det er muligt at få udstedt et ID kort fra test STS'en som følger:
|
ID kortet kan herefter anvendes i til en feks. et kald fra SoapUI eller andre klienter.
Forudsætninger:
- Adgang til security token service
- At certifikatet Lis_Rasmussen_Laege.jks.jks, har password Test1234 og er tilknyttet CVR 25450442