Module 26: Debugging and Testing
Testing habits, with and without AI
🏠The everyday picture
Locking the stable before the horse escapes. When a bug is found, you fix it and fit a lock so the same horse can't escape again.
📘What it really is
-
Test the edges, where bugs live: empty lists, zero, one item, very large numbers, negative numbers, missing properties, text where a number is expected, Hindi text in a name.
-
One bug, one test: when you find a bug, first write a test that fails because of it, then fix the code until it passes.
-
Test-first (also called TDD): write the test before the function. It forces you to decide exactly what the function should do, which is useful thinking before asking AI to write it.
-
Asking AI for tests: AI writes tests quickly, but check them:
- do they test behaviour you care about, or just repeat the code?
- do they include edge cases and bad input?
-
would they actually fail if the code were wrong? (Break the code and see.)
-
Never "fix" a failing test by changing what it expects unless you've decided the old expectation was wrong. And never let an AI delete or skip a failing test to make the run go green.
-
Keep tests fast, so you'll actually run them after every change.
🖱️Try it
Choose searchProducts from Module 22. Ask an AI to write tests for it. Read them, add any edge cases it
missed, then break searchProducts in two different ways and check that the tests catch both breaks.
✅Quick check
An AI says "I fixed the failing tests" and you see it changed the expected values in the tests. What do you do?
Show the answer
Check carefully. If the code was wrong, the tests were right; ask it to fix the code instead.
What's the first thing to do when you find a bug, before fixing it?
Show the answer
Write a test that fails because of the bug.
