Environments & Test Library

This page describes where each test runs and how reusable test cases are managed. It is part of the Testing Concept.

Test Environments

Each test type needs a suitable environment. The environment is a central quality factor.

Environment	Purpose	Typical use
Local developer environment	Fast feedback during daily work	Unit, adapter, frontend, and API tests
CI and temporary test setups	Reproducible automated execution	Unit, adapter, frontend, API, and integration tests
VCluster	Isolated system-level run	System tests
Develop	Consolidated development environment	E2E tests
Staging	Community acceptance	Manual tests of real user scenarios
Penetration test environment	External security testing	Penetration test by Port Zero
Local deployment platform from the deployment repository	Platform-level validation	Early integration and deployment tests

Local Environments in the Code Repository

Each component defines its own local test environment. Each exposes different classes of defects.

Component	Local environment
portal-backend	Docker Compose in dev-environment/backend
portal-frontend	Keycloak and a local .env file
authz/e2e	A complete AuthZ test environment
config-adapter	Maven and Testcontainers
model-forge	Maven and Testcontainers

For the local setup of the whole platform, see Local Development Setup.

CI and Temporary Test Setups

When a merge request is created in GitLab, CI runs unit, adapter, frontend, and API tests. Integration tests check whether several components work together.

System and Platform Environments

The deployment repository shows the real platform structure. System tests are defined and run there:

• They check relationships between platform parts, not only one service.
• They run in an environment that combines APISIX, authentication, backend, adapter, and the relevant data components.
• They run a functional use case fully automatically and check its result.

The local development environment does not run on Kubernetes. It is therefore not a suitable basis for production-like system tests.

Test Library

The test library supports the development process. Each new feature starts from a tested base. The functionally and technically stable part of a feature becomes part of the library and a precondition for later features.

Developer Test Library

The developer test library is defined and built during feature development. It is used for system tests and developer E2E tests. It contains:

• Reusable preconditions.
• Prepared system states.
• Stable intermediate steps.
• Standard happy-path building blocks.
• Clearly documented dependencies.

Example: Feature 1 creates test case 1 and test case 2. Feature 2 additionally needs test case 3. When Feature 1 is stable, it becomes part of the preconditions for Feature 2. The library grows with the platform.

New tickets use these labels:

Label	Purpose
dev::usecase	Functional use case
dev::testcase	Detailed test case

These tickets define functional use cases, model and stabilize preconditions, refactor E2E building blocks, expand the library systematically, and prevent technical debt in E2E automation.

Community Test Library

UAT and execution tickets describe the community E2E tests at a functional level. The Quality Assurance Working Group defines, creates, and runs them. They contain:

• Functional use case descriptions.
• Clearly defined test goals.
• Defined roles and preconditions.
• Specific execution steps.
• Expected results.
• Documented dependencies and test data.

A functional process is first described in a UAT test case. It is then divided into executable tickets that cover individual scenarios or parts of the process. A functional change is first added to the UAT test case and then to the execution tickets. This creates a traceable path from the functional goal to the test execution.

Label	Purpose
uat::test-case	Description of the functional use case
uat::execution	Execution of specific scenarios