Module 30: Programming Project
Error handling and testing the whole program
🏠The everyday picture
A shop's soft opening: invite friends, let them try to break things, fix what goes wrong, then open to the public.
📘What it really is
-
Validate at the edges: everything from outside (typed input, files, APIs) is checked once when it enters, then the rest of the code can trust it. Use
unknownfor raw input and narrow it to your types (Module 27). -
Clear messages for people ("Amount must be a positive number, like 250"), technical details in logs.
- Test plan:
- unit tests for every calculation and rule (Module 26), including edge cases;
- a few tests that run whole flows: add a product, record stock received and sold, check the stock and totals;
- storage tests: save then load gives the same data; a missing or broken file is handled;
-
manual testing from your requirements list, one by one.
-
Check each requirement has at least one test, and note it in
REQUIREMENTS.md. - Run everything before each commit:
npm run check && npm test.
🖱️Try it
Write a test for each requirement that doesn't have one. Then try to break the program by hand: negative amounts, text instead of numbers, a deleted data file, a data file with broken JSON, selling more stock than exists. Fix each problem and add a test for it.
✅Quick check
What does "validate at the edges" mean?
Show the answer
Check all data from outside (input, files, APIs) once, as it enters; then inner code can rely on it.
Your data file contains broken JSON. What should happen?
Show the answer
A clear message, no crash, and no silent loss of data (for example, keep a backup of the broken file and start fresh only after telling the person).