Testing Overview

Testing is a first-class part of Toodle development. Every change to the frontend (Toodle repository), the backend (toodle-api repository) or the documentation (toodle-docs repository) is expected to pass automated checks before it is merged, and user-facing behaviour is additionally validated through a formal feedback process.

This section of the documentation describes the complete testing practice:

Page	Contents
User Feedback Process	The formal, repeatable process for collecting and acting on stakeholder and user feedback
Automated Testing	The automated test suites, how to run them, what they cover, and how CI executes them
Testing Policy	The team's rules about what must be tested, when tests may be skipped, and what blocks a merge
Testing Plan	The original testing strategy and scope
Sprint 2 Verification	Record of a full-suite execution with results and findings

What testing looks like in each repository

Repository	Layer	Framework	CI checks
Toodle (frontend)	Component, UI smoke, helper and dev-proxy tests	Vitest + Testing Library (jsdom)	Lint, format, test, production build
toodle-api (backend)	Unit, route integration and opt-in PostgreSQL tests	Vitest + Supertest (Node)	Lint, format, test with coverage
toodle-docs (documentation)	Link and build validation	MkDocs --strict	Documentation build workflow

Test pyramid

The automated suites follow a classic test pyramid: many fast unit tests at the base, fewer integration tests in the middle, and a small number of full-stack checks at the top.

graph TD
    A[Opt-in PostgreSQL suites<br/>real database transactions] --> B[Route integration tests<br/>Express app + Supertest]
    B --> C[Unit tests<br/>services, controllers, middleware]
    C --> D[UI component tests<br/>Testing Library]
    D --> E[Smoke & dev-tooling tests]

The backend is described from the top down in Automated Testing; the frontend in Automated Testing.

How the pieces fit together

1. Local development — developers run lint, tests and build commands before pushing (see Automated Testing).
2. Continuous integration — both Toodle and toodle-api run CI workflows in Gitea (and mirrored GitHub Actions) on every push and pull request to main and develop. Failing checks block review and merge (see Automated Testing).
3. Coverage — Vitest coverage reports are generated locally and uploaded to Codecov in CI, enforcing the targets defined in Testing Policy.
4. Human verification — stakeholder meetings and structured user testing produce feedback that is tracked, actioned and retested (see User Feedback Process).
5. Documentation — this site is built with mkdocs build --strict so broken links or missing pages fail the build.

Scope of the automated suites

The current suites verify:

• API routes, request validation, authentication, RBAC and ownership boundaries;
• business rules for allocations, course applications, sessions, swaps, excusals, overflow work and timesheets;
• UI component rendering, form submission, error display and role-gated flows;
• the in-app problem reporting modal that feeds the user feedback process;
• Vite dev-proxy behaviour against a real local HTTP server.

What the suites do not yet prove is recorded honestly in Sprint 2 Verification: live Auth0 token exchange, real PostgreSQL locking and concurrency, and browser-level end-to-end flows. The PostgreSQL suites in toodle-api/tests/integration exist for the database boundary and are opt-in by design.