Testdatageneratoren er en webapplikasjon som kan brukes for å generere syntetiske testdata til bruk i utvikling og testing. Applikasjonen gir brukeren mulighet til å skrive en spesifikasjon av de testdataene som ønskes generert. Spesifikasjonen blir validert mot forretningsregler og gyldig input, og deretter genereres et xml-dokument med data som samsvarer med den angitte spesifikasjonen, samt eventuelle felter som har blitt automatisk fylt ut (f.eks. fødselsnummer, organisasjonsnummer, beløp) i den grad brukeren ikke angir disse feltene selv i spesifikasjonen.
Testdataene som genereres er syntetiske, og er basert på test-personer og -enheter som hentes fra Tenor.
Denne aktuelle løsningen som er publisert på Github er en forenklet og nedkortet versjon av den Testdatageneratoren som brukes internt i Skatteetaten, og denne løsningen er derfor ment å brukes kun som et utgangspunkt og som eksempelkode for andre som ønsker å lage og videreutvikle en tilsvarende løsning innenfor sitt domene. Denne forenklede versjonen gir mulighet for å generere dokumenter kun av typen "SaldoRente", som er innrapportering av innskudd, utlån og renter fra bankene, men koden kan utvides til å generere en rekke andre dokumenttyper.
Testdatageneratoren består av tre komponenter:
- tdg-frontend er brukergrensesnittet som lar brukeren definere en spesifikasjon for testdata som skal genereres. Spesifikasjonen skrives som et internt utviklet DSL (kalt "TestData Spesifikasjonsspråk"/TDSS) basert på Kotlin. TDSS'en er definert i tdg-backend. Frontenden gjør kall til tdg-kotlin-compiler-server for løpende validering av spesifikasjonen, og fra frontenden sendes deretter spesifikasjonen til tdg-backend.
- tdg-backend består av to moduler.
- tdss definerer domenespråket (TDSS) og bestemmer hva som er lov å spesifisere i frontenden.
- testdatagenerator tar imot spesifikasjonen, genererer testdata i xml-format og returnerer denne til frontenden.
- tdg-kotlin-compiler-server er en tjeneste som gir highlighting, autocomplete og feilmeldinger for spesifikasjonen som skrives i frontenden. Valideringen gjøres mot tdss-modulen i tdg-backend. tdg-kotlin-compiler-server er en forket versjon av Jetbrains sin Kotlin compiler server, som deretter har blitt tilpasset Skatteetatens domene.
testdatagenerator og tdg-kotlin-compiler-server bruker tdss som bibliotek. Innsendingene er tekst i TDSS streng-format, som kan komme fra frontend eller HTTP-klienter. korrelasjonsId brukes for å hente assosierte dokumenter via HTTP.
tdg-kotlin-compiler-server er en tilpasset fork av JetBrains sin Kotlin compiler server, brukt som “språkserver” for TDSS i Testdatageneratoren.
Den kompilerer og evaluerer Kotlin-kode som sendes inn fra tdg-frontend, og gir tilbake feilmeldinger, highlighting og autocomplete-forslag mens brukeren skriver spesifikasjonen.
I denne varianten er serveren utvidet med støtte for TDSS ved å legge til tdss biblioteket som avhengighet og ved å tilpasse completion-logikken.
Legg til i dependencies/build.gradle.kts:
kotlinDependency("no.skatteetaten.rst:tdss:${tdssVersjon}")
Legg til i build.gradle.kts:
implementation("no.skatteetaten.rst:tdss:${tdssVersjon}")
Legg til egen logikk i CompletionProvider.kt
Hvis man ikke har et remote repository som distribuerer tdss, så må tdg-backend bygges først, slik at det lages et lokalt snapshot av tdss.
I gradle.properties må man sette tdssVersjon=1.0-SNAPSHOT.
Prosjektet må bygges med Java 17.
- Bygg prosjektet.
$ ./gradlew build -x test - Start applikasjonen.
$ ./gradlew bootRunkcs-dev.http kan brukes til å teste ut kotlin-compiler-server ved hjelp av IntelliJ sin HTTP-syntaks.
README fra Jetbrains sin kotlin-compiler-server
A REST server for compiling and executing Kotlin code. The server provides the API for Kotlin Playground library.
Download Kotlin dependencies and build an executor before starting the server:
$ ./gradlew build -x test Start the Spring Boot project. The main class: com.compiler.server.CompilerApplication
To build the app inside a Docker container, run the following command from the project directory:
$ ./docker-image-build.shBased on aws-serverless-container.
$ ./gradlew buildLambdaGetting .zip file from build/distributions.
Lambda handler: com.compiler.server.lambdas.StreamLambdaHandler::handleRequest.
Publish your Lambda function: you can follow the instructions in AWS Lambda's documentation on how to package your function for deployment.
Add Kotless and remove aws-serverless-container =)
Swagger url: http://localhost:8080/api-docs/swagger-ui/index.html
Just put whatever you need as dependencies
to build.gradle.kts via a
task called kotlinDependency:
kotlinDependency "your dependency"
NOTE: If the library you're adding uses reflection, accesses the file system, or performs any other type of security-sensitive operations, don't forget to configure the executor.policy . Click here for more information about Java Security Policy.
How to set Java Security Policy in executors.policy
If you want to configure a custom dependency, use the marker @LIB_DIR@:
grant codeBase "file:%%LIB_DIR%%/junit-4.12.jar"{
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
permission java.lang.RuntimePermission "setIO";
permission java.io.FilePermission "<<ALL FILES>>", "read";
permission java.lang.RuntimePermission "accessDeclaredMembers";
};
Set the environment variables
| ENV | Default value |
|---|---|
| ACCESS_CONTROL_ALLOW_ORIGIN_VALUE | * |
| ACCESS_CONTROL_ALLOW_HEADER_VALUE | * |
We use prod spring active profile to stream logs as JSON format.
You can set the spring profile by supplying -Dspring.profiles.active=prod or set env variable SPRING_PROFILES_ACTIVE to prod value.
In case of an unsuccessful execution in the standard output will be the event with INFO level:
{
"date_time": "31/Aug/2021:11:49:45 +03:00",
"@version": "1",
"message": "Code execution is complete.",
"logger_name": "com.compiler.server.service.KotlinProjectExecutor",
"thread_name": "http-nio-8080-exec-1",
"level": "INFO",
"level_value": 20000,
"hasErrors": true,
"confType": "JAVA",
"kotlinVersion": "$kotlinVersion"
}- Update the kotlin version in libs.versions.toml
- Make sure everything is going well via the task:
$ ./gradlew build- Save branch with the name of the kotlin version. Pattern:
/^[0-9.]+$/(optional) - Bump version on GitHub releases (optional)
Gradle Build Scans can provide insights into an Kotlin Compiler Server Build. JetBrains runs a Gradle Develocity server. that can be used to automatically upload reports.
To automatically opt in add the following to $GRADLE_USER_HOME/gradle.properties.
org.jetbrains.kotlin.compiler.server.build.scan.enabled=true
# optionally provide a username that will be attached to each report
org.jetbrains..kotlin.compiler.server.build.scan.username=John WickAlso you need to create an access key:
./gradlew provisionDevelocityAccessKeyA Build Scan may contain identifiable information. See the Terms of Use https://gradle.com/legal/terms-of-use/.
sdk use java 17.0.15-tem