Testing Strategy¶
Testing was an important part of Toodle's development process. Infinite Loopers used automated tests, manual verification, user feedback and continuous integration to check that the application behaved correctly and that new changes did not introduce regressions.
Our testing approach covered the React frontend, Express backend, database interactions and documentation.
Testing Approach¶
The team combined several testing methods to verify different aspects of Toodle.
| Testing Area | Approach | Tools |
|---|---|---|
| Frontend | Component rendering, interactions, forms and role-specific interfaces | Vitest, React Testing Library |
| Backend | Business logic, validation, authentication and API behaviour | Vitest, Supertest |
| Database | Transaction, persistence and relationship checks | Prisma, opt-in PostgreSQL tests |
| Integration | API routes, request handling and connected workflows | Supertest, manual application testing |
| User Acceptance | Task-based feedback and usability evaluation | Feedback forms, user testing |
| Performance | Page loading, asset sizes and responsiveness | Lighthouse, Vite build analysis |
| Documentation | Navigation, links and build validation | MkDocs |
These approaches complemented one another. Automated tests provided repeatable checks, while manual testing and feedback helped identify usability issues that automated tests might not detect.
Automated Testing¶
Frontend Testing¶
The frontend repository, Toodle, uses Vitest and React Testing Library to test React components and user interactions.
Frontend tests cover areas such as:
- Component rendering and navigation.
- Form input, validation and submission.
- Loading, success and error states.
- Role-specific user interfaces.
- Course applications and tutor workflows.
- Session swaps and related interactions.
- In-app problem reporting.
- Shared components and helper functions.
Authentication and API dependencies can be mocked to test interface behaviour without requiring live external services.
The frontend also includes tests for development tooling, including the Vite API proxy.
Backend Testing¶
The backend repository, toodle-api, uses Vitest and Supertest for unit and API integration testing.
Unit tests focus on individual services, controllers, middleware and validators.
API integration tests exercise the Express application through HTTP requests, checking behaviour such as:
- Successful and unsuccessful requests.
- Input validation and error responses.
- Authentication and role restrictions.
- Resource ownership and course-specific permissions.
- Course applications and approvals.
- Tutor allocations and eligibility rules.
- Availability and scheduling conflicts.
- Timesheets, excusals and session swaps.
- Overflow work and other tutor-management operations.
Most automated backend tests use mocked external services and database behaviour. This allows the team to test business rules without modifying production data.
Database Integration Testing¶
Some backend integration tests use a real PostgreSQL database to verify behaviour that cannot be fully demonstrated through mocks.
These tests are opt-in and require a dedicated disposable test database.
They are kept separate from the default test suite because they depend on additional infrastructure and may create or modify test records.
The test configuration must never point to the production or shared university database.
Running Automated Tests¶
Tests are run from the relevant repository after installing its dependencies.
Frontend¶
npm test
npm run test:coverage
npm run lint
npm run build
Backend¶
npm test
npm run test:coverage
npm run lint
Documentation¶
python -m mkdocs build --strict
The documentation build checks the MkDocs configuration and reports issues such as invalid navigation or broken internal documentation links.
On Windows PowerShell, npm.cmd may be used instead of npm when required by the local execution policy.
Test Coverage¶
Both application repositories use coverage tooling to help identify code that is not exercised by automated tests.
The documented coverage targets are:
| Coverage Measure | Target |
|---|---|
| Lines | 70% |
| Functions | 70% |
| Statements | 70% |
| Branches | 60% |
| Changed-line coverage | 60% |
Code Coverage Results¶
The team used Codecov to monitor automated test coverage across the frontend and backend repositories.
| Repository | Reported Coverage | Coverage Report |
|---|---|---|
Frontend (Toodle) |
80% | View Frontend Codecov Report |
Backend (toodle-api) |
92% | View Backend Codecov Report |
Both reported coverage figures exceed the project's 70% coverage target.
Codecov provides additional information about covered and uncovered code, helping the team identify areas that may require further testing.
These percentages represent the reported coverage results and should be interpreted alongside automated test outcomes, integration testing and manual verification.
Coverage reports are generated using Vitest and can be uploaded to Codecov through the configured CI workflows.
Coverage percentages are useful indicators, but they do not guarantee that every possible behaviour or error has been tested.
The team therefore also considers whether tests cover important success cases, failure cases and permission boundaries.
Continuous Integration¶
Toodle uses Gitea Actions to automate checks across its repositories.
The main CI activities include:
| Repository | Automated Checks |
|---|---|
| Frontend | Linting, formatting, automated tests and production build |
| Backend API | Linting, formatting, automated tests and coverage checks |
| Documentation | Strict MkDocs build |
Automated workflows help identify errors before changes are integrated into the main development branches.
The team also established dedicated cloud-hosted Gitea runners to improve the reliability and availability of CI execution.
For further details, see Methodology → CI/CD Runner Infrastructure.
Manual and Workflow Testing¶
Automated testing was supplemented with manual checks of the application.
These checks focused on whether users could complete the workflows relevant to their roles.
| Role | Example Workflows |
|---|---|
| Administrator | User management, staff access and course administration |
| Lecturer | Course coordination, tutor applications, allocations and approvals |
| Tutor | Availability, allocations, timesheets, excusals and session swaps |
| Student | Onboarding, tutoring applications and volunteering opportunities |
Manual testing also considered navigation, error handling, mobile responsiveness and consistency between frontend and backend behaviour.
Testing individual components does not necessarily prove that an entire workflow functions correctly in a deployed environment. For this reason, the team also used the integrated application for practical verification.
Regression Testing¶
Regression testing was used to check that changes did not negatively affect existing functionality.
For bug fixes, the team aimed to reproduce the original problem through an automated test where practical.
When an automated regression test was not suitable, the affected workflow could be checked manually.
Relevant checks were repeated following changes to ensure that previously working functionality remained available.
Issues identified during these checks were recorded and managed through Jira.
See Bug Tracking for the issue-resolution process.
User Acceptance and Usability Testing¶
User feedback was collected to evaluate how effectively people could navigate and use Toodle.
Participants completed role-related tasks and provided feedback on the application's clarity, usability and overall experience.
The feedback helped identify improvements relating to navigation, onboarding, mobile interfaces and tutor-management workflows.
Issues raised through feedback sessions and in-app problem reports were considered during further development and testing.
The detailed feedback approach and findings are documented under User Feedback & Usability.
Performance Verification¶
The team also examined frontend performance, particularly page loading and asset sizes.
Performance work included:
- Route-level code splitting.
- Separating third-party JavaScript into vendor chunks.
- Optimising application images.
- Reducing unnecessary API requests.
- Comparing build sizes before and after optimisation.
Lighthouse and production build analysis were used to evaluate these changes.
The recorded results and supporting measurements are available under Performance Verification.
Testing and Quality Process¶
Testing formed part of the team's development and review workflow.
Before merging a change, contributors were expected to:
- Run the relevant linting and formatting checks.
- Run automated tests for the affected functionality.
- Verify that the application builds successfully.
- Manually check important behaviour where appropriate.
- Resolve identified failures.
- Submit the work for review through a Pull Request.
The configured CI workflows provided additional verification.
Where checks were skipped or infrastructure was unavailable, the limitation needed to be considered when interpreting the test results.
Recorded Verification Evidence¶
Testing results were recorded at different stages of development.
For example, verification performed on 14 September 2026 recorded:
| Check | Recorded Result |
|---|---|
| Frontend automated tests | 42 passed |
| Backend automated tests | 356 passed, 11 skipped |
| Frontend and backend linting | Passed |
| Frontend production build | Passed |
| Prisma schema validation and client generation | Passed |
These results represent a historical Sprint 2 verification run, not the final test totals for the completed application.
Additional tests and features were introduced in later development.
The current test totals should be taken from the latest successful CI runs rather than earlier verification records.
Testing Limitations¶
Different testing methods provide different levels of assurance.
Most unit and route integration tests use mocks for external services and database operations. They therefore do not independently prove live Auth0 authentication, actual database concurrency behaviour or complete browser-level workflows.
Real PostgreSQL tests provide additional database-level evidence but are not part of the default test execution.
Manual workflow checks and user feedback provide further confidence in the integrated application, although they do not replace comprehensive automated end-to-end testing.
These distinctions are important when interpreting the team's testing results.
Summary¶
Toodle's testing strategy combined automated testing, continuous integration, manual workflow verification, performance analysis and user feedback.
This approach allowed Infinite Loopers to identify defects throughout development, check important business rules and improve the application's reliability and usability.
Testing was treated as an ongoing part of development rather than an activity performed only before final submission.