Testing your program as you go
Computer Science · Key Stage 1 · The School
Building it all, then testing
Add ten blocks to a program without running it once. Then press go. It does not work. Which of the ten blocks caused that? You cannot tell. Any one of them could be wrong, or several at once. You are back to searching everywhere.
Testing after every block
Add ONE block. Run it. Check it does what you expected. Add the NEXT block. Run it again. If something breaks now, you already know exactly where to look — the block you just added. That is the only place the bug can be.
Slower per step, faster overall
Testing after every block feels slower, because you stop so often. But it is much faster overall. Finding a bug among ten new blocks can take a long time. Finding a bug in ONE new block takes moments. Small, frequent checks beat one big search at the end.
Building a maze program two ways
Build a program that walks a sprite through a maze, ten blocks long. Way one: add all ten blocks, then run it once. It hits a wall on block six, but you have to check all ten to find that. Way two: add block one, test. Add block two, test. By block six, the sprite hits the wall the moment you add it, and you know instantly which block is wrong. Same maze, same ten blocks — only the testing habit was different.
Making it a habit
Every time you add something new, run it before adding more. It feels like extra work at first. Soon it becomes automatic, and it saves far more time than it costs, because a bug never gets the chance to hide behind other bugs.