Skip to content

Testing Guidelines

Principles

  • Test cases are independent — no shared mutable state between tests.
  • Test public interfaces, not internal implementation.
  • Unit-test the happy path and all boundary cases.
  • Tests are deterministic — no sleep, no wall-clock time, no unfixed random seeds.
  • Inject clocks, UUID generators etc. that are controllable by the test driver
  • No network or file-system access in unit tests.

Test Pyramid (Martin Fowler)

  • Unit tests — fast, isolated, the majority. Mock only at architectural boundaries.
  • Integration tests — test component interactions at boundaries; always use BDD; may be written in a different language (e.g., Python/Behave).
  • End-to-end tests — minimal; critical user journeys only.

BDD

  • Use cases are covered by BDD integration tests.
  • Structure: Given / When / Then.
  • Preferred frameworks: Godog (Go), Behave (Python), Catch2 (C++), Cucumber + JUnit 5 (Java).
  • The feature files in this repository are meant as documentation and executable tests. They are primarily serving the developers, in order to support development. They are executed together with the unit tests, if possible. Therefore, in this repository, they must not be understood as actuale end-to-end tests, but rather as more expressive unit and component tests. As a result, mocks might be used instead of actual infrastructure components, in order to keep the tests fast and focused on the logic of the use cases.

Mocking

  • Mock only at layer boundaries (e.g., infra interfaces defined in usecase).
  • Never mock domain or use-case logic — test it directly.

Test Data

  • Use builders or factories; avoid large inline literals.
  • Never depend on test execution order.

Directives

  • Test public interfaces, not internal implementation; tests are independent and deterministic
  • No sleep, wall-clock time, or unfixed random seeds; inject clocks and UUID generators
  • No network or file-system access in unit tests
  • Mock only at architectural layer boundaries (infra interfaces defined in usecase); never mock domain logic
  • Every use case must have a BDD scenario (Godog for Go, Behave for Python, Catch2 for C++, Cucumber+JUnit for Java)
  • Use builders or factories for test data; never depend on test execution order
  • BDD tests contained herein are meant for developers. They are not meant as actual end-to-end tests. Therefore, mocks may be used instead of actual infrastructure components