Test from the module to the end-to-end journey

The foundation provides several testing levels because no single level is enough. A business rule can be correct in isolation and fail once connected to PostgreSQL. An API can respond correctly yet remain unusable in the browser. The test plan connects these levels.

1. Fast unit tests

They cover pure functions, Zod schemas, calculations, permissions, data transformations, error mapping, and isolated components. They provide fast feedback during development and let you name each invariant precisely.

Examples: a capability matches a pattern, an invalid date is rejected, a pasted cell is converted to the correct type, and a tampered encrypted key cannot be decrypted.

2. Integration tests

They exercise real adapters: PostgreSQL repositories, transactions, migrations, Redis, RabbitMQ, object storage, or file parsers. They verify what mocks cannot prove, such as a SQL constraint, a transaction rollback, or messaging channel recovery.

Costly external dependencies remain replaced by controlled test doubles. The goal is to test the technical boundary, not call a third-party service on every commit.

3. API tests

Controllers are exercised over HTTP with their guards, validation, and serialization. For a protected route, the useful minimum goes beyond the happy path:

• 400 for invalid input;
• 401 without a valid identity;
• 403 without the required capability;
• rejection of a resource from another tenant or project;
• success with the correct identity;
• an audit trail when the action requires one.

4. Frontend tests

Kit components have their own tests for keyboard interaction, selection, templates, errors, and asynchronous states. Pages then add application rules: forms, routing, loading, and component composition.

A useful frontend test verifies observable behavior. It avoids reproducing in the assertion the internal implementation it is meant to protect.

5. End-to-end journeys

End-to-end scenarios combine the layers across a small number of critical journeys:

1. local or SSO login;
2. tenant and project selection;
3. authorized business action;
4. persistence and reload;
5. presence of the expected audit record;
6. revocation or denial with another role.

For an import, the scenario can upload a file, correct a row, validate the batch, then check the result in the business list. For a mapping application, it can filter a category, open a marker, and confirm that the corresponding record respects permissions.

01End to endCritical journeys through browser, API, and persistence

02API and frontendRoutes, permissions, pages, and component composition

03IntegrationRepositories, messaging, storage, and migrations

04UnitBusiness rules, schemas, transformations, and components

CI assembles the evidence

The pipeline combines linting, type checking, targeted tests, tests with infrastructure, OpenAPI contracts, and a smoke test of the generated template. The suites that are actually mandatory depend on the delivered repository: the project documentation must list those that block a merge.