Debugging and Testing

One-sentence summary

Debugging means finding and fixing a problem in a Scratch project step by step; in this lesson we learn to run blocks one at a time, watch a variable on the stage and test slowly.

Why does it matter?

When a game does not work on the first try, that is not a failure. Code rarely does exactly what we want the very first time we write it. What matters is being able to find exactly where the problem is.

In the algorithm module we learned that debugging has a method: write down the expected result, observe what actually happens, break the program into smaller parts and find the first point where the result becomes different. Scratch is a great place to practise this method, because we can see blocks as they run, try them one at a time and watch variables right in front of us.

Once my cat sprite kept getting stuck in a wall. At first I thought the code was wrong. When I ran the blocks one by one, I saw the problem was the wrong event block at the top. This lesson shows how to find that kind of problem in an orderly way.

How do we find a problem in Scratch?

Running blocks one at a time

If you click on a stack of blocks in Scratch, that stack runs once immediately, and a short yellow glow appears around it. This is the fastest way to see whether one part works correctly on its own.

For example, if a character does not move at all, we first test just the movement part:

move 10 steps

If the sprite slides to the right when we click this block, the movement block is fine. So the problem is somewhere else; perhaps the event that should run this block is never triggered.

Watching a variable on the stage

If you tick the box next to a variable in the Variables category, its value appears live in a corner of the stage. That way you can watch the number change with your own eyes while the code runs.

Say the score is not going up. We show the score variable on the stage and play the game:

when green flag clicked
set score to 0
forever
  if <touching mouse-pointer?> then
    change score by 1

If the score counter on the stage climbs very fast, the condition is being counted as true again and again on every frame. Seeing when the number changes tells us where the problem is.

Testing slowly

Sometimes code runs so fast that we cannot see what happened. Two tricks help. First, make sure Scratch's "Turbo Mode" is turned off. Second, add a short wait inside the loop:

forever
  wait 1 seconds
  next costume

By slowing the costume change with wait 1 seconds, we can watch each step and easily find which step the problem starts at. Once we find it, we can remove the wait and return to normal speed.

Recognising common bugs

The wrong event block

Every stack of code should start with an event (from the Events category). The most common bug is attaching code to the wrong event instead of when green flag clicked.

Suppose we want the jump code to run when the space key is pressed:

when this sprite clicked
change y by 50

Here the code runs when the sprite is clicked with the mouse, not when the space key is pressed. The correct version is:

when space key pressed
change y by 50

If a character does not react at all, the first thing to check is the event block at the very top.

No wait inside a loop

The forever loop is very fast. If there is no wait inside it, the computer runs the loop hundreds of times per second. This can make a sprite look like it vanished in an instant, or make a sound stutter as it plays over and over.

when green flag clicked
forever
  start sound Meow

This code restarts the "Meow" sound again and again without letting it finish, and the result is a crackle. The fix is to wait for the sound to finish:

when green flag clicked
forever
  play sound Meow until done

Clones that are never cleaned up

Clones are copies of a sprite; games use them to create bullets or enemies. If a clone is not deleted when it leaves the stage or hits an enemy, hundreds of invisible clones pile up and the game slows down.

Wrong: a clone is created but never deleted.

when I start as a clone
forever
  move 10 steps

Better: let the clone delete itself when it reaches the edge.

when I start as a clone
forever
  move 10 steps
  if <touching edge?> then
    delete this clone

The delete this clone block removes a finished copy from the stage and keeps the project fast.

Mini practice

The code below has a problem. The goal: when the green flag is clicked, the cat should walk to the right and stop at the edge. But the cat never stops.

when green flag clicked
forever
  move 10 steps

Steps:

1. Write the expected result: "The cat will stop when it reaches the edge."
2. Observe what actually happens: The cat goes off the edge and comes back, never stopping.
3. Find the missing part: There is no condition asking "am I touching the edge?".
4. Fix it and try again.

Try to write the fixed code yourself, then compare it with the solution below:

when green flag clicked
forever
  move 10 steps
  if <touching edge?> then
    stop all sounds
    stop [this script]

Here we used the <touching edge?> condition from the Sensing category and the stop block from the Control category. To practise watching a variable on the stage, you can also show the x position value and follow how far the cat travels.

Common mistakes

Guessing the problem from the start

Instead of staring at the whole program and saying "it's probably there," it is faster to run the parts one at a time and move forward with proof.

Changing many things at once

If you change five blocks in one attempt, then even if it starts working you will not know which change did the job. Change one thing at a time and test again.

Forgetting to show the variable on the stage

It is hard to find score or lives bugs without seeing how the number changes. The first move is to make the relevant variable visible on the stage.

Testing without starting from the green flag

If you test without running the when green flag clicked block that sets variables to their starting values, leftover values from the previous game will mislead you. Click the green flag before every test.

Safety note

This lesson is done entirely on screen, inside Scratch, and needs no hardware. Even so, be careful not to stay at the screen too long: take a short break every 20–30 minutes, rest your eyes and move around a little. If you share your project on the Scratch website, review comments and shares together with an adult, and never write your real name, school or address in your projects.

Lesson summary

• Debugging means finding and fixing a problem in an orderly way; code that does not work on the first try is normal.
• You can test one part on its own by clicking a single stack of blocks.
• Showing a variable on the stage lets you see live how its value changes.
• Adding a short wait to a loop and testing slowly shows which step the bug starts at.
• The most common bugs are: the wrong event block, no wait inside forever, and not cleaning up clones.

Check questions

1. What happens when you click a stack of blocks, and why is that useful?
2. How does making a variable visible on the stage help with debugging?
3. Why do we sometimes add a short wait inside a forever loop?
4. If a character does not react to a key at all, which block should you check first?
5. What problem appears if a clone that leaves the stage is never deleted?

Answers

1. That stack runs once immediately, and a short yellow frame glows around it. This lets you see whether that part works correctly on its own, separated from the rest of the project.
2. The variable's value appears live in a corner of the stage. By watching with your eyes when and how the number changes, you can tell where in the code the problem starts.
3. A forever loop runs very fast. A short wait slows the steps down enough to see them, so we can notice which step the bug appears at.
4. The event block at the very top. If the code is attached to the wrong event (for example when this sprite clicked instead of when space key pressed), the character will not respond to the key.
5. Invisible clones pile up on the stage. This slows the project down and can confuse checks such as collisions. To prevent it, a finished clone should be removed with delete this clone.

Source and verification note

For “Debugging and Testing”, verification focuses on whether the relationship between How do we find a problem in Scratch? and Watching a variable on the stage remains consistent across examples. Block names are kept consistent with the current core Scratch categories. Project behaviour should be tested separately for start-up, normal play, errors and restarting.

Next lesson

Project: Maze Game