Testing and review
🏠The everyday picture
Before a new hospital wing opens, inspectors walk through every room with a checklist, and nurses do a practice shift. Problems found then are cheap; problems found with patients aren't.
📘What it really is
-
Automated tests (Module 39): key components, the table's filters and sorting, forms, and the API states with MSW.
-
Requirement walkthrough: go through every requirement in the running app and note the result.
- Quality checklist:
- keyboard only, screen reader, 200% zoom;
- phone and desktop sizes;
- slow network and offline;
- empty data, one item, thousands of items;
- Lighthouse for performance and accessibility;
-
no console errors or warnings.
-
Code review: read your own code as if someone else wrote it. Better: ask a fellow learner, or ask an AI to review the pull request, then decide which comments are right (Builder Path, Lesson 5).
-
Write up what's done, what isn't, and known issues in the README. Honesty about limits is professional.
🖱️Try it
Open a pull request for your dashboard project (Module 10). Ask an AI to review it, and respond to each comment:
fix it, or explain why not. Run the full quality checklist and record the results in TESTING.md.
✅Quick check
An AI review suggests 15 changes. Do you make them all?
Show the answer
No. Judge each one: fix what's right, and explain why for the rest.
Why record known issues in the README?
Show the answer
So users and future developers (including you) know the limits, rather than discovering them by surprise.