Testing Plan

Testing is used throughout Toodle to verify that features work correctly, requirements are met, and changes do not break existing functionality.

The testing approach combines automated testing, manual verification, and review before merging.

Testing Strategy

Area	Approach	Status
Frontend	Component and user-interface testing	🟡 Planned / In Progress
Backend API	Unit and integration testing	🟡 Planned / In Progress
Authentication	Manual login and access testing	✅ In Use
Database	Validate stored data and relationships through application workflows	🟡 In Progress
Integration	Test frontend, API and database together	🟡 In Progress
User Acceptance	Stakeholder and user feedback	⬜ Planned

Current Verification

The following behaviour has already been manually verified on the deployed application:

• the application can be accessed online;
• users can authenticate using Google through Auth0;
• authenticated users can access Toodle successfully; and
• a logged-in student can be recognised with the STUDENT role.

These checks provide an initial confirmation that deployment, authentication and role recognition are communicating correctly.

Frontend Testing

Frontend testing will focus on:

• pages rendering correctly;
• navigation between views;
• forms accepting and validating input;
• role-specific interfaces;
• responsive behaviour;
• clear error messages; and
• accessibility of important actions.

Automated frontend tests will be added as features become stable.

API Testing

Backend testing will verify:

• endpoints return the expected responses;
• invalid requests are rejected correctly;
• authentication is required where appropriate;
• role restrictions are enforced;
• business rules are applied correctly; and
• database operations create, update and retrieve the expected records.

API routes should be tested independently before being connected to the frontend.

Core Workflow Testing

Important Toodle workflows will be tested end-to-end.

Examples include:

1. user signs in;
2. the correct role is identified;
3. an organiser views tutors and courses;
4. a tutor is considered for an allocation;
5. allocation constraints are checked;
6. valid data is stored; and
7. the updated information is displayed correctly.

Later workflows will include timesheets, excusals and overflow work.

Pre-Merge Quality Checks

Before work is merged into develop, the contributor should:

1. run the lint command configured for the repository;
2. run relevant automated tests;
3. run the project's build or validation command;
4. manually review the affected feature;
5. resolve any failures;
6. open a Pull Request; and
7. obtain review before merging.

Only checks that are configured in the relevant repository are required.

For the documentation repository, the current validation command is:

```bash python -m mkdocs build --strict