Page History
| Navitabs | ||||||
|---|---|---|---|---|---|---|
| ||||||
Indledning
Dette dokument beskriver en testvejledning for
...
KIDS indlæseren. Det forudsættes at projektet er bygget og installeret, og med denne vejledning kan man således afvikle
...
tests og derved kontrollere robustheden.
...
KIDS indlæseren benytter i vid udstrækning docker til test, for at kunne teste så vidt muligt med de rigtige afhængigheder.
Det overordnede setup er beskrevet i NSP Continuous Integration & Delivery, og det er herved muligt at starte en specifik
...
KIDS indlæser med lokalt kørende database
...
således at hele flowet kan afprøves lokalt.
Unittest
Der anvendes unittests i
...
KIDS indlæseren ved brug af JUnit.
...
KIDS indlæserens unittest-setup er specielt
...
da der benyttes TestContainers, således at unittests kan ramme en rigtig lokalt kørende mariadb database
...
kørende i docker (https://www.testcontainers.org).
Unittests kan køres ved at eksekvere
|
Mocking i Camel
...
|
...
Unittests med en kørende MariaDb
...
Idet KIDS indlæseren vil ikke selv migrere databaseskemaet men til testen er det blevet godkendt at unittests selv starter en mariadb database via docker, og tester ved brug af den.
TestContainers er et java bibliotek som tillader programmatisk instruering af docker starter op, og herved starter en ny tom mariadb container op, som applikationen kan køre databasemigreringer mod, og herefter benytte i alle unittests.
For eksempel se https://svn.nspop.dk/svn/importers/
...
kidsindlaeser/trunk/src/test/java/dk/nsi/sdm/
...
kids/BaseTest.java klassen i
...
KIDS indlæser-projektet.
Codecoverage
Efter afvikling af unit-tests genereres en testrapport med Maven-plugin’et JaCoCo. Rapporten kan ses ved at åbne følgende fil i en browser target/site/jacoco/index.html.
Rapporten dækker selve
...
KIDS indlæseren. Codecoverage er minimum 79%. Der henvises til JaCoCo testrapporten for yderligere information vedr. coverage. Bemærk at JaCoCo ikke kan verificere linjer, der kaster exceptions, og at sådanne linjer altid vil stå som missed.
Pr.
...
26. november
...
2021 er coverage
...
Integrationstest
En stor del af de automatiserede tests udfører integrationstest da de verificerer indlæsningen af en fil og det resultat der kommer ud af det.
For at kunne teste yderindlæseren sammen med dens aftager, SKRS er der lavet specielle automatiserede tests, som kan køres som integrationstests.
Disse integrationstests giver mulighed for at teste hele indlæseren med de afhængigheder den vil benytte sig af, når den kører i produktion, som fx. SKRS (registerkopiservice) eller SYES (enkeltopslagsservicen).
Tests til integrationstests er markeret i koden med en custom testkategori og projektet er sat op så disse kan køres ved at køre (mvn test -Pintegrationtest).
Disse tests kræver at indlæseren samt de korrekte afhængigheder allerede kører, hvilket typisk laves via docker-compose. For yder indlæseren er compose/test/docker-compose.yml lavet således, at denne starter en yder indlæser, database samt SKRS i en opsætning, som kan testes via integrationstestene. Så man kan starte denne docker-compose fil lokalt (docker-compose up) og så ved siden af køre integrationstestene, som vil lægge en fil op, vente på at den bliver indlæst, og herefter se efter i både database samt SKRS om indlæsningerne er gået godt.
Performancetest
Yder indlæseren indeholder ikke en automatiseret testsuite beregnet til performancetest. Det anbefales dog at der udføres en manuel performancetest i forbindelse med udvikling, med yder filer af omtrent samme størrelse og kompleksitet som de rigtige indlæsningsfiler.
...
85%:
