Indledning

Dette dokument beskriver en testvejledning for yder indlæseren. Det forudsættes at projektet er bygget og installeret, og med denne vejledning kan man således afvikle integrations- og performancetests og derved kontrollere robustheden.

Yder indlæseren benytter i vid udstrækning docker til integrations test, for at kunne teste så vidt muligt med de rigtige afhængigheder.

...

Der anvendes unittests i yder indlæseren ved brug af JUnit.Yder indlæserens unittest-setup er specielt på to punkter, i det der benyttes mocks for at kunne teste Camel, samt at 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

I det Camel kører asynkront, er det nødvendigt for unittests at vide, hvornår Camel er færdig med at indlæse en fil, hvis testen skal vide, hvornår den kan kontrollere, om det gik som forventet. Dette gøres i yder indlæseren, i klassen BaseMockTest, hvor Camel-routen mockes ved at tilføje et sidste MockEndpoint, som en test kan vente på.

Yderindlæseren anvender fælles bibliotekets test pakke, til at understøtte en lang række unit test.

Der kan læses mere om unit test i indlæseren i "Guide til udviklere fælles for alle stamdataindlæserne"Hvis ikke der benyttes mocks til Camel kan man være nødsaget til at indsætte waits, hvilket gør testeksekveringen langsommere, samt kan være forskellige afhængig af eksekveringsmaskinens computerkraft.

Unittests med en kørende MariaDb

I det yder indlæseren selv indlæseren selv migrerer databaseskemaet (via FlywayLiquibase), samt i overensstemmelse med NSP husregler ikke benytter ORM som Hibernate, 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/yderindlaeser/trunk/src/test/java/dk/nsi/sdm/yder/BaseTest.java klassen i yder indlæser-projektet.

Integrationstest

) anvender unit testene in memory databasen H2.

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 yder 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. 19. november 2020 er coverage 84%:

Image Added

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 Til yder indlæseren foreslås det, at der laves 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).

Unittests til integrationstests markeres i koden med en custom testkategori og projektet sættes op så disse Integrations test kan køres ved at køre (mvn test -Pintegrationtest).eksekvere

Disse tests vil så kræve 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. Det local development compose setup er lavet med et galera cluster med flere instanser.

Docker compose startes med:

Testene kan fejle pga. manglende rettigheder til de anvendte ftp foldere (sker når docker selv opretter dem). Dette kan løses med "sudo chmod 777 test_sftp" (og test_sftp_ekstern).

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. 

En sådan rudimentær performancetest er ment til at afdække eventuelle flaskehalse som kan blive optimeret før release, samt også give en idé til hvor lang tid yder indlæseren vil indlæseren vil skulle bruge for at indlæse de typiske filer der modtages.

Manuelle Test

Manuel test af Beckup

Yderindlæseren har 3 mulige indstillinger for at backup ifm. indlæsningen. Enten kan indlæsning ske uden backup (NoBackup), almindeligt backup, hvor filen gemmes i originalt format (RawBackup) eller komprimeret backup, hvor filen gemmes som zip fil (ZipBackup).

Under udvikling er det muligt at teste funktionaliteten af backup. I nedenstående eksempel testes Zip backup. Der er testet vha. scripts afviklet mod en lokal YderIndlæser startet op i Docker.

1. Tjek indhold af yder.properties
   

   Code Block
   language bash title Terminal
   yderindlaeser % grep backup.type compose/configuration/yder.properties backup.type=ZipBackup

2. Indlæse en valid fil
   

   Code Block
   language bash title Terminal
   yderindlaeser % cp dk.nsp.sdm.yder-service/src/test/resources/data/ny_yder/FourYder.xml compose/development/test_input/

3. Tjek indhold af backup-folder
   

   Code Block
   language bash title Terminal
   yderindlaeser % ls -liatr compose/development/test_backup total 40 17035342 drwxr-xr-x@ 12 user group 384 Dec 17 14:10 .. 21276796 drwxr-xr-x 3 user  group     96 Dec 17 14:12 . 21277072 -rw-r--r-- 1 user  group  18216 Dec 17 14:12 FourYder-20407418-3538-42f7-902c-fb897de32842.zip

4. Tjek status af service
   

   Code Block
   language bash title Terminal
   yderindlaeser % curl http://localhost:8080/yderindlaeser/status {"DataSetLog":"OK","SFTP YDER_EXTERNAL":"OK","SFTP YDER":"OK","Database":"OK","Processing":"Dataprocessering OK"}

5. Tjek status fra databasen
   

   Code Block
   language bash title Terminal
   yderindlaeser % docker exec -it development-mariadb-galera-0-1 mysql -uyder -pyder -Dyder -e"select * from YDS_dataset_status;" +-----+--------------------------------------+-------------+---------------------+ | PID | UUID | StatusValue | Status | +-----+--------------------------------------+-------------+---------------------+ | 1 | 20407418-3538-42f7-902c-fb897de32842 | 10 | RECEIVED | | 4 | 20407418-3538-42f7-902c-fb897de32842 | 30 | PREPARSED | | 7 | 20407418-3538-42f7-902c-fb897de32842 | 50 | PARSED_AND_SPLITTED | | 10 | 20407418-3538-42f7-902c-fb897de32842 | 70 | COMPLETED | +-----+--------------------------------------+-------------+---------------------+