3. Architecture

This framework is designed to follow extension model patterns, so we can extend any functionality just by adding dependencies into the classpath. As an example, Quarkus applications will be deployed locally, but if we add the OpenShift dependency, then we can automatically deploy it into OpenShift cluster just by adding the @OpenShiftScenario annotation to the same scenario.

Concepts

• Scenario - where are you going to deploy your services? Existing scenarios are: @QuarkusScenario for Baremetal, @OpenShiftScenario for OpenShift and @KubernetesScenario for Kubernetes.
• Services - how test cases interact with resources? Existing services are: DefaultService when you don't need to interact with the service, RestService when you want to call REST endpoints, ... you can see the full list of existing services in here.
• Resources - what are you going to deploy? Existing options are Quarkus applications and Containers.
• Managed Resource - how resources are going to be deployed in the target scenario?

Extension Points

• Scenario extension point - create your own custom scenario. Example: OpenShiftExtensionBootstrap.java registered in META-INF/services/io.quarkus.test.bootstrap.ExtensionBootstrap.
• Resources extension point - create your own annotations to deploy custom resources. Example: Annotation KafkaContainer.java registered in META-INF/services/io.quarkus.test.bootstrap.AnnotationBinding using the binding KafkaContainerAnnotationBinding.java
• Managed Resources extension point - deploy your resources into the target scenario. Example: Kafka Managed Resource for OpenShift implementation registered in (META-INF/services/io.quarkus.test.services.containers.KafkaContainerManagedResourceBinding)[https://github.com/quarkus-qe/quarkus-test-framework/blob/main/quarkus-test-service-kafka/src/main/resources/META-INF/services/io.quarkus.test.services.containers.KafkaContainerManagedResourceBinding] using the binding OpenShiftStrimziKafkaContainerManagedResourceBinding.java

Packages

Modules within the testing framework must conform to the following package naming conventions:

• io.quarkus.test.bootstrap - manage the lifecycle of the tests
• io.quarkus.test.bootstrap.inject - services that are injectable at test method level
• io.quarkus.test.configuration - configuration facilities
• io.quarkus.test.logging - logging facilities and handlers
• io.quarkus.test.tracing - tracing facilities
• io.quarkus.test.scenarios - scenarios that the module implement, eg: @OpenShiftScenario
• io.quarkus.test.scenarios.annotations - useful JUnit annotations to disable/enable scenarios
• io.quarkus.test.services - services that the module implement, eg: @QuarkusApplication, @Container
• io.quarkus.test.services.<service-name> - bindings to configure the service-name to be extended or supported
• io.quarkus.test.utils - more utilities