Skip to content

Latest commit

 

History

History
125 lines (87 loc) · 2.81 KB

TECHNICAL.adoc

File metadata and controls

125 lines (87 loc) · 2.81 KB

Technical aspects

Design decisions

Technologies used

  • Gradle (for building project)

  • Kotlin (for production code)

  • Groovy (for testing with Spock)

  • PACT (for contract testing)

  • Cucumber (for functional testing)

  • WebFlux + Reactor (for reactive implementation)

Requirements

  1. Has at least JVM 17 to build and run the project

  2. You should set up you own OpenWeather APIKEY as an environment variable:

export OPEN_WEATHER_MAP_API_KEY=yourapikey
Note
 You can create you onw key here

Running

  • To build the entire app with:

./gradlew build

  • To build the entire app but without running any tests:

./gradlew build -x test -x contractTest

  • To run integration tests:

./gradlew integrationTest

  • To run contract tests:

./gradlew contractTest

  • To run functional tests:

./gradlew functionalTest
Note
 Functional tests are running the entire app inside a docker container, so it requires a up & running docker environment and an app image built previously (see below)

  • To publish artifacts (including app fat jar and server stubs):

./gradlew build publishToMavenLocal

  • To run the entire app in localhost:

./gradlew bootRun

Once up & running you can check and interact with the REST API using OpenAPI UI

  • To build a DOCKER image with the app fat jar:

./gradlew app:bootBuildImage

Getting Technical Insights

  • To print what will be the task graph planned by gradle when targeting a specific task:

./gradlew tiTree [target task]

  • To get dependencies report of every configuration set:

./gradlew htmlDependencyReport

If you run app in DEV mode you can also see all insights offered by Actuator:

SPRING_PROFILES_ACTIVE=dev ./gradlew bootRun

KNOWN errors

  • Integration tests written using Spock are running during gradle test task instead of integrationTest task despite being correctly classified with tag @Tag(TestClassification.INTEGRATION). As a workaround I’m using classification by name to distinguish them:

    • Unit tests named as *Test

    • Integration tests name as *IT

What could be improved?

  • GITHUB base CI pipeline

  • Providing secrets in a secured way

  • Use Factories for test data fixtures

  • Embrace variability in tests (i.e.: Time provider, Variable Weather conditions)

  • Review the possibility of mixing both Contract and API definition as single source of truth