Owner: Engineering Team | Last Updated: 2026-01-30 | Status: Current
This page documents the testing strategy and standards for the WWAI project. It covers the current state of testing across all platforms, the manual testing procedures developers follow today, and a phased plan for introducing automated testing.
Honest assessment: The WWAI web application currently has no automated test suite. No test runner is configured. No unit tests, component tests, integration tests, or end-to-end tests exist. The backend and mobile app testing status has not yet been formally documented. All quality assurance today relies on manual testing performed by developers before and after each deployment.
This page serves two purposes:
| Platform | Test Framework | Runner | CI Integration | Status |
|---|---|---|---|---|
| Web App (Next.js) | None | None | None | No test suite configured |
| Backend (Django) | pytest (presumed) | pytest | Not documented | To be documented |
| Mobile App (Flutter) | Flutter test (presumed) | flutter test | Not documented | To be documented |
There is no Jest, Vitest, Playwright, Cypress, or any other testing tool installed or configured in the web application. The package.json contains no test script. There are no __tests__ directories and no *.test.ts or *.spec.ts files in the codebase.
This is the starting point. The sections below describe what we do today and where we are headed.
Until automated tests are in place, every developer must manually verify the following before considering a feature or fix ready for deployment. This checklist is mandatory, not optional.
| # | Test Case | Expected Result |
|---|---|---|
| 1 | Log in with a free plan account | Feature restrictions are enforced correctly; gated features show upgrade prompts |
| 2 | Log in with a paid plan account | Full access to all plan features; no restriction modals appear |
| 3 | Use an account with insufficient credits | "Not enough credits" error is displayed; action is blocked; user is guided to purchase more |
| 4 | Use an account with a paused subscription | Pause modal appears; user cannot access paid features until subscription is resumed |
| # | Test Case | Expected Result |
|---|---|---|
| 5 | Switch through all 8 locales and verify new UI strings | All new or changed strings render correctly in: en, de, es, fr, it, pt, zh, nl |
Check for:
| # | Test Case | Expected Result |
|---|---|---|
| 6 | Upload a .docx file |
File is accepted, text is extracted, content appears in editor |
| 6 | Upload a .pdf file |
File is accepted, text is extracted, content appears in editor |
| 6 | Upload a .txt file |
File is accepted, text content appears in editor |
| # | Test Case | Expected Result |
|---|---|---|
| 7a | Submit text with exactly 50 words (minimum) | Text is accepted and processed without error |
| 7b | Submit text with fewer than 50 words | Validation error is shown; submission is blocked |
| 7c | Submit text at 150,000 characters (maximum) | Text is accepted and processed without error |
| 7d | Submit text exceeding 150,000 characters | Validation error is shown; submission is blocked or text is truncated with a warning |
| # | Test Case | Expected Result |
|---|---|---|
| 8 | Check Sentry for new errors after deploy | No new error spikes; any new errors are triaged and tracked |
| # | Test Case | Expected Result |
|---|---|---|
| 9a | Test on mobile viewport (375px width) | Layout is usable; no horizontal scroll; touch targets are adequate |
| 9b | Test on tablet viewport (768px width) | Layout adapts correctly; sidebar behavior is appropriate |
| 9c | Test on desktop viewport (1440px width) | Full layout is displayed; no wasted space or misalignment |
| # | Test Case | Expected Result |
|---|---|---|
| 10a | Test in Google Chrome (latest) | All functionality works correctly |
| 10b | Test in Mozilla Firefox (latest) | All functionality works correctly |
| 10c | Test in Safari (latest) | All functionality works correctly; especially check file uploads and CSS rendering |
The following plan describes how automated testing will be introduced incrementally. Each phase builds on the previous one. The goal is to reduce reliance on the manual checklist over time, not to eliminate it entirely.
Framework: Vitest
Vitest is the recommended test runner because it is fast, supports native ESM, and is compatible with the Next.js and TypeScript toolchain already in use.
What to test first:
Target files:
utils/*.ts -- Pure utility functionshooks/*.ts -- Custom hooks containing business logic (test the logic, not the React lifecycle)Why start here: These files contain critical business logic (credit math, plan enforcement, score calculations) that directly affects revenue and user trust. They are also the easiest to test because they are pure functions with no UI dependencies.
Setup tasks:
test script to package.jsonFramework: Vitest + React Testing Library
What to test:
Focus: Test business logic and user interactions, not visual regression. Do not write snapshot tests for styling. Test what the user sees and can interact with.
Setup tasks:
@testing-library/jest-domFramework: Playwright
What to test:
Approach: Mock backend API responses to isolate front-end behavior. Tests should not depend on a live backend or database. Use Playwright's route interception to provide deterministic API responses.
Setup tasks:
Framework: Playwright (same installation as Phase 3)
What to test: Full user journeys running against the staging environment with a real backend.
Critical paths:
Approach: These tests hit real APIs on the staging environment. They are slower and more brittle than integration tests. Run them on a schedule (nightly or before release) rather than on every commit.
Setup tasks:
| Language | Test File Pattern | Example |
|---|---|---|
| TypeScript | *.test.ts or *.spec.ts |
creditUtils.test.ts |
| TypeScript (React) | *.test.tsx or *.spec.tsx |
ScoreDisplay.test.tsx |
| Python | test_*.py |
test_humanizer.py |
| Dart | *_test.dart |
detector_test.dart |
Tests should be co-located with their source files or placed in a __tests__/ directory at the same level.
src/
utils/
creditUtils.ts
creditUtils.test.ts <-- co-located (preferred)
components/
ScoreDisplay/
ScoreDisplay.tsx
ScoreDisplay.test.tsx <-- co-located (preferred)
__tests__/ <-- alternative: grouped test directory
integration/
loginFlow.spec.ts
Use describe blocks that match the component or function name. Use it or test blocks with descriptive names that read as sentences.
describe('calculateCreditsRequired', () => {
it('returns 1 credit for text under 500 words', () => {
// ...
});
it('returns 2 credits for text between 500 and 1000 words', () => {
// ...
});
it('throws an error when word count is below minimum', () => {
// ...
});
});
These targets apply once automated tests exist. They are goals to work toward, not requirements that must be met on day one.
| Category | Target Coverage | Rationale |
|---|---|---|
| Critical business logic (credits, limits, scores) | 90%+ | Directly affects revenue and user trust; errors here are high-impact |
| Utility functions | 90%+ | Pure functions are easy to test; no excuse for low coverage |
| UI components | 70%+ | Focus on interaction tests (clicks, form submissions, conditional rendering) |
| Pages | 50%+ | Test basic render and key interactions; full page tests are expensive |
| API routes | 80%+ | Validate request handling, error responses, and authentication checks |
Do not spend time writing automated tests for the following:
getServerSideProps is called by the framework or that routing works. These are framework responsibilities.The manual testing checklist and automated testing plan are complementary, not mutually exclusive.
| Manual Checklist Item | Automated Replacement (When Available) |
|---|---|
| Free plan restrictions | Phase 2: Component tests for plan restriction UI |
| Paid plan access | Phase 2: Component tests for feature access logic |
| Insufficient credits error | Phase 1: Unit tests for credit calculations; Phase 2: Component tests for error display |
| Paused subscription modal | Phase 2: Component tests for subscription state handling |
| Locale verification (8 locales) | Phase 2: Component tests with locale context mocking |
| File upload formats | Phase 3: Integration tests for upload flow |
| Text boundary conditions | Phase 1: Unit tests for validation functions |
| Sentry monitoring | Remains manual -- always check Sentry after deploy |
| Responsive design | Phase 3: Playwright viewport tests (partial); visual review remains |
| Cross-browser testing | Phase 4: Playwright multi-browser runs (partial); manual spot-checks remain |
Even after automated tests are in place, Sentry monitoring and visual review will remain manual activities. Automated tests reduce the burden of the checklist but do not eliminate the need for human judgment.
| CI/CD Pipelines | Test automation in pipelines |
| Code Review Checklist | Review criteria including tests |
| Debugging Production | Production debugging with tests |
| Date | Author | Change |
|---|---|---|
| 2026-01-30 | Admin | Rewrote page: added manual testing checklist, phased automation plan, coverage targets, and conventions |
| 2026-01-30 | Admin | Initial creation |
Prev: API Design Guidelines | Next: Documentation Standards | Up: General