Principles & Ownership

The Testing Concept describes the target state of quality assurance for the CIVITAS/CORE platform, including the Portal, Config Adapter, AuthZ, Model Forge, the deployment environments, and community-supported acceptance testing. It combines established test management principles with the structure of the civitas-core-platform and civitas-core-deployment repositories. For the layout of these repositories, see Project Structure.

The goal is to find defects early and to verify changes so that they are traceable, reproducible, and tested in a suitable environment. The concept answers three questions:

1. What must be tested at each level?
2. Which environment is suitable for each test?
3. Who is responsible for setup, execution, and evaluation?

The concept is split into four pages:

• Principles & Ownership: principles, test pyramid, responsibilities, external contributions (this page).
• Test Levels & Matrix: test levels and types, and the test matrix by component.
• Environments & Test Library: test environments, developer and community test library.
• Quality Gates & Outlook: entry and exit criteria, gates, and planned extensions.

note

The Testing Concept describes the target state. Not every part exists yet. Contract testing, for example, is part of the target state, but the repositories contain no contract test setup at the moment. The medium-term and long-term extensions are listed in Outlook. Existing tooling is named in Test Levels and Test Environments.

Test Management Principles

The following principles are binding.

Risk-Based Approach

Not every function needs the same test depth. Critical paths with a high functional or technical impact receive more coverage than rarely used functions or functions that are easy to roll back. For CIVITAS/CORE this means:

• Security-relevant paths have their own tests.
• Data flows and permission flows have high priority.
• Model management receives special attention because it is central to the platform.
• Core platform use cases receive more testing than edge cases.
• Integration and deployment have their own quality levels.

Test Pyramid

The strategy follows a test pyramid. Many fast, low-cost tests sit at the bottom. Fewer, but meaningful, integration and system tests sit in the middle. Very few, but valuable, end-to-end and acceptance scenarios sit at the top.

Several components and runtime environments interact in the platform. A large E2E suite is therefore expensive, fragile, and hard to maintain. The E2E suite stays small, and reusable preconditions separate the scenarios (see Test Library).

Shift Left and Shift Right

• Shift left: Find defects as early as possible, in unit, component, and integration tests.
• Shift right: Validate real use, side effects, operational behavior, and community feedback at later test levels.

Technical correctness alone is not enough. The platform must work in real processes, with real roles, and in realistic environments.

Reproducibility and Idempotence

Tests must be repeatable, especially CI runs, API tests, and E2E scenarios. This requires:

• A defined test data strategy.
• Defined setup and teardown steps.
• Assertions that tolerate resources that already exist.
• Find-first or create-if-missing patterns.
• A clear separation between test state and production logic.

Traceability and Functional Clarity

Each test links to a functional requirement, a use case, or a platform behavior. A test is complete only when it is clear which functional question it answers, which component it covers, which environment it needs, and which risk it reduces.

Ownership

Role	Responsibility
Frontend	UI behavior and user flows
Backend	APIs and business logic
Feature teams	Flows across components and across the platform
DevOps	Deployment, operations, and smoke tests
UX/UI	Clarity, usability, and documentation
Community	Functional use and user acceptance tests
Port Zero	External penetration test
CORE team	Development of the strategy; monitoring and improving quality assurance

External Contributions

Community contributions must meet the same quality criteria and provide the same test coverage as internal changes. This is straightforward for unit and integration tests. System tests and E2E tests require more coordination, so the internal quality assurance functions run them for external contributions.

If a contribution adds a new third-party component to the deployment, system tests are mandatory:

• Add an entry to the test library in the deployment repository (tests/system/TEST_LIBRARY.md).
• Add a new use case that tests the extension on the happy path.