Most of the students would waste most of their time in lab sessions adding and removing printf statements to one huge `main` function, and trawling through the resulting mess on the console.
I was quite satisfying to guide them through the process of:
- Articulating exactly what they're looking for in the console (e.g. "these numbers should add up to the same as that")
- Have them write that down in the code (e.g. `mu_assert("results add up", x + y == z);`)
- Remove the corresponding printf calls
Due to sheer amount of output from printf, many students had cobbled together elaborate nested-if-based one-char-at-a-time scanf-parser menu systems to choose which parts of the program to run with which inputs; the results being far more complicated than the actual programming assignments they'd been given! Since tests only output when they fail, all of this complication could be thrown away.
Then, the magic parts:
- Leave the tests in place, so they'll be checked every time
- Keep adding more tests to narrow down a problem more specifically
- Wrap the tests in `for (int i = 0; i < 1000000; i++) { ... }` to check far more cases than would be feasible manually
Besides driving home the idea of automation, testing across many inputs in a loop usually made debugging easier. Due to the effort of setting up, checking and tearing out printf debugging statements, many students had skipped checking trivial cases like 0 and 1, and instead were trying to wade through the output for an input like 50. Adding a loop caused those trivial cases to be checked, and the problems became obvious :)
Most of the students would waste most of their time in lab sessions adding and removing printf statements to one huge `main` function, and trawling through the resulting mess on the console.
I was quite satisfying to guide them through the process of:
- Articulating exactly what they're looking for in the console (e.g. "these numbers should add up to the same as that")
- Have them write that down in the code (e.g. `mu_assert("results add up", x + y == z);`)
- Remove the corresponding printf calls
Due to sheer amount of output from printf, many students had cobbled together elaborate nested-if-based one-char-at-a-time scanf-parser menu systems to choose which parts of the program to run with which inputs; the results being far more complicated than the actual programming assignments they'd been given! Since tests only output when they fail, all of this complication could be thrown away.
Then, the magic parts:
- Leave the tests in place, so they'll be checked every time
- Keep adding more tests to narrow down a problem more specifically
- Wrap the tests in `for (int i = 0; i < 1000000; i++) { ... }` to check far more cases than would be feasible manually
Besides driving home the idea of automation, testing across many inputs in a loop usually made debugging easier. Due to the effort of setting up, checking and tearing out printf debugging statements, many students had skipped checking trivial cases like 0 and 1, and instead were trying to wade through the output for an input like 50. Adding a loop caused those trivial cases to be checked, and the problems became obvious :)