Lesson 2 of 64 in this sequence

Not completed yet

Saved on this device only — not synced to an account yet.

Learning path

Step 2 of 64

Continue the sequence

ResumeReturn to this step ReviewRevisit the core idea RemediateGet repair practice Next stepChoose the next lesson manually

Completion

Review objectives and instruction
Complete the activity with manual learner confirmation
Answer every understanding-check item
Show completion feedback and reward only after the learner finishes the check

Progress

Step 2/64
15 content types
AI help source context available
Auto-advance blocked

Review objectives and instruction

AI help

Available only with source grounding, privacy limits, age controls, and measurement.

AI source context

Debugging a Program by Testing One Step at a Time · Building Programs (Programming) · 1B-AP-15 · debugging

Evidence: local lesson AI-help metadata only; source-grounding, privacy, age-safety, and measurement hooks do not prove real model quality, production telemetry, child AI approval, or AI tutor production readiness

Production AI readiness not claimed

AI source context

Assessment shape

Local lesson assessment shape is complete.

Local shape only; production answer-attempt telemetry, live ownership/RLS evidence, mastery interpretation, release, and production readiness are not claimed here.

Objectives: 4
Activity: Prompt ready
Quiz items: 3 items, 3 answer keys, 3 explanations
Reward: Completion reward ready

Assessment progress stays manual: do not auto-advance through uncertain answers, failed writes, consent, media, payment, learner choice, or AI-assisted checks.

Learning-loop evidence: Content-map contract only; persistence and production learner-progress writes require route/API evidence.

Manual policy: assessment, media, consent, payment, learner choice, failed writes, and AI-uncertain help stay under learner control.

Prerequisite: Complete or review Breaking a Big Problem into Smaller Steps; Use with parent or guardian controls for child learners

AI guardrails

Privacy

Do not send raw child free text without consent
Use source excerpts and non-identifying progress state only
Asset is not registry-gated

Age safety

Apply kids audience controls before AI-help claims
Keep child learner AI paths behind guardian/product review evidence before readiness claims

Measurement

Log AI help usage by surface and asset slug
Evaluate answer quality against source-grounded rubric before production-readiness claims
Tie remediation prompts to completion, retry, or review outcomes

Local AI-help guardrails only; they do not prove guardian approval, production telemetry, model evaluation, release, deployment, or AI tutor production readiness.

Source and rights

Source path: koydo-app/scripts/curriculum-authoring
License: ai-generated-koydo
Attribution: Attribution decision needs owner review
AI provenance: claude-opus-4-8

Source review gates: attribution_missing

Local source evidence only; this does not prove publication rights, attribution approval, AI provenance clearance, release, deployment, or production readiness.

Route review

Current route: /library/kids/computer_science/en/lesson/debugging-by-testing
Route source: Fallback route needs owner canonical review
Candidate route: /library/kids/computer_science/en/lesson/debugging-by-testing

Local route evidence only; fallback candidates need owner-approved canonical route policy before route writes, production discoverability, or readiness claims.

Content gates: canonical_target_web_missing_uses_library_fallback

lessonslessonslesson objectivesmedia scenesdrillspractice setsquizzesfeedbackcharacterscitationsconcept mapsprogressresumereviewremediationnext steps

Debugging a Program by Testing One Step at a Time

with Byte

Byte the robot sits at a wooden workbench covered in colorful recipe cards, carefully comparing a freshly baked but slightly burned cookie to the perfect golden cookie drawn on the card, scratching their head with a pencil and circling step 3 with a red marker.

Explain what a bug is and why programs sometimes do the wrong thing.
Identify which step in a program caused an unexpected result.
Compare what a program actually does to what you expected it to do.
Predict what will happen when a bug is fixed and the program is run again.

Key terms

Bug: A mistake that makes a program go wrong.
Debugging: Hunting for and fixing a program's mistake.
Expected: What you thought the program would do.
Actual: What the program really did when it ran.

What a Bug Is

A bug is a mistake hiding in your program. When a bug is there, the program does the wrong thing, like baking cookies that come out burned. Bugs are normal and every programmer finds them. The good news is that you can hunt them down and fix them one step at a time.

Test One Step at a Time

Do not try to check everything at once, because that gets confusing fast. Instead, check step one, then step two, then step three. At each step, look at what really happened. Keep going slowly until you reach the step where something went wrong. That careful checking is how good detectives work.

Expected Versus Actual

The bug hides in the gap between what you expected and what actually happened. If you expected golden cookies but got burned ones, that gap is your clue. Find the step where the real result is different from the result you wanted. That surprising step is where the bug is hiding.

Worked examples

A drink machine should pour juice but pours water.

Check step one: did it pick the right cup? Yes, that looks fine.
Check step two: did it pick juice? No, it picked water. That is the bug.

Answer: The bug is in step two, where it chose water instead of juice.

You expected a blue square but got a blue circle.

The color blue is right, so that step is fine.
The shape is wrong, so the shape step holds the bug.

Answer: The bug is in the step that chose the shape.

Hi, I'm Byte! Let's talk about debugging — that's the word programmers use when they hunt for mistakes in a program. Imagine you wrote a recipe program for baking cookies. You run it, and the cookies come out burned. Something went wrong! But where? Here's the trick: don't try to check everything at once. Test ONE step at a time. First, check step 1 — did the oven temperature get set correctly? If that looks fine, move to step 2 — did the timer count down right? Keep going until you find the step where what ACTUALLY happened is different from what you EXPECTED to happen. That gap between expected and actual is where your bug is hiding! Once you fix that step, run the program again and check — are the results better now? Testing one step at a time is like being a detective: you gather clues until you catch the culprit.

Activity

Byte's sandwich-making program already has the steps in the right order — tap the one step that caused the sandwich to come out wrong.

Practice

Describe what you would check first to find a bug.

Explain what expected and actual results mean in your own words.

Common mistakes to avoid

Check every step at onceTesting one step at a time helps you find the exact bug faster.
A program has only one bugA program can have more than one bug, so keep testing after a fix.

Check your understanding

Byte's drawing program is supposed to make a blue square, but it draws a red circle instead. What is the BEST first step to find the bug?

Mia finds a bug in step 3 of her program. She fixes it and runs the program again. The result (output) is still wrong. What should Mia do next?

What does it mean when what a program ACTUALLY does is different from what you EXPECTED it to do?

Recap

Debugging means hunting for mistakes in a program. Test one step at a time and compare what actually happened to what you expected. The step where they are different is where the bug hides, so fix that step and run again.

Reflect

What is one thing a careful detective does when stuck?