Student Note
Programming is not just about writing code. Programmers must also test, debug, and document their programs to make sure they work correctly.
Even professional programmers make mistakes. Debugging and testing help programmers find errors, fix problems, and improve the quality of their programs.
1. What Is Debugging?
Debugging is the process of finding and fixing errors in a program.
A bug is a mistake in the code that causes the program to act incorrectly or not run at all.
Example
A programmer wants the program to display:
Welcome to AP CSP!
But the program displays:
Welcome to AP CSA!
The programmer must debug the program by finding the incorrect text and fixing it.
2. Why Is Debugging Important?
Debugging is important because it helps programmers:
- Find mistakes in code
- Fix programs that do not run
- Correct programs that give wrong answers
- Improve program reliability
- Make programs easier to understand
- Prevent future errors
A program may look correct but still produce the wrong output. Testing and debugging help catch these problems.
3. Common Types of Programming Errors
There are three common types of programming errors:
- Syntax errors
- Logic errors
- Runtime errors
4. Syntax Errors
A syntax error happens when code breaks the rules of the programming language. The program usually will not run until the syntax error is fixed.
Common Syntax Errors
- Missing quotation marks
- Missing parentheses
- Misspelled commands
- Missing commas
- Incorrect indentation
- Missing brackets or braces
Example
DISPLAY("Hello World"
This code has a syntax error because the closing parenthesis is missing.
Corrected Version
DISPLAY("Hello World")
5. Logic Errors
A logic error happens when the program runs, but it gives the wrong result. Logic errors can be harder to find because the program does not always crash.
Example
A program is supposed to calculate the average of two numbers.
average ← number1 + number2 / 2
This may give the wrong answer because division happens before addition.
Corrected Version
average ← (number1 + number2) / 2
The parentheses make sure the numbers are added first.
6. Runtime Errors
A runtime error happens while the program is running. The program may start correctly but stop because something unexpected happens.
Common Runtime Errors
- Dividing by zero
- Trying to access an invalid list index
- Using a variable before it has a value
- Entering the wrong type of input
Example
score ← 100 / 0
This causes a runtime error because a number cannot be divided by zero.
7. What Is Testing?
Testing is the process of running a program to check whether it works correctly.
Testing helps programmers find bugs before users use the program.
Testing Answers These Questions
- Does the program run?
- Does the program produce the correct output?
- Does the program handle normal input?
- Does the program handle unusual input?
- Does the program handle invalid input?
- Does the program meet the requirements?
8. Test Cases
A test case is a specific input and expected output used to check whether a program works correctly.
Example Test Case
A program adds two numbers.
| Input | Expected Output |
|---|---|
| 3 and 4 | 7 |
| 10 and 5 | 15 |
| -2 and 8 | 6 |
If the program gives the expected output, the test passes. If the program gives a different output, the programmer needs to debug the program.
9. Normal Test Cases
A normal test case uses typical input that the program is expected to handle.
Example
A program checks whether a student passed a class.
IF grade >= 70
{
DISPLAY("Pass")
}
ELSE
{
DISPLAY("Fail")
}
| Grade | Expected Output |
|---|---|
| 85 | Pass |
| 72 | Pass |
| 55 | Fail |
10. Boundary Test Cases
A boundary test case checks values at the edge of a condition. Boundary testing is important because many errors happen at the edges.
Example
If a student passes with a grade of 70 or higher, important boundary values are:
| Grade | Expected Output |
|---|---|
| 69 | Fail |
| 70 | Pass |
| 71 | Pass |
Testing 70 is especially important because it is the exact cutoff.
11. Invalid Test Cases
An invalid test case uses input the program should not normally accept. These tests help programmers make sure the program handles errors safely.
Example Invalid Inputs
A program asks for a student’s age. Invalid inputs could include:
- -5
- 0
- "hello"
- blank input
The program should not crash. It should respond with a helpful message.
Please enter a valid age.
12. Incremental Testing
Incremental testing means testing small parts of a program as they are written.
Instead of writing the entire program first, programmers test each section step by step.
Why Incremental Testing Helps
- Errors are easier to find
- Problems are fixed earlier
- The programmer knows which part caused the issue
- The final program is more reliable
Example
If creating a calculator program, test:
- Addition first
- Then subtraction
- Then multiplication
- Then division
- Then the menu system
13. Using Print Statements for Debugging
One simple debugging strategy is to display values while the program runs. This helps programmers see what the program is doing.
score ← 85
DISPLAY(score)
The programmer can check whether the variable contains the correct value.
Example With a Message
DISPLAY("Current score is: " + score)
14. Tracing Code
Tracing code means carefully following each line of code and keeping track of variable values.
x ← 5
y ← 3
x ← x + y
DISPLAY(x)
Trace Table
| Step | x | y | Output |
|---|---|---|---|
| Start | undefined | undefined | none |
| x ← 5 | 5 | undefined | none |
| y ← 3 | 5 | 3 | none |
| x ← x + y | 8 | 3 | none |
| DISPLAY(x) | 8 | 3 | 8 |
15. Debugging With Comments
Comments can help programmers explain what code is supposed to do. A comment is text in the code that the computer ignores.
// Calculate the average score
average ← total / numberOfScores
16. What Is Documentation?
Documentation is written information that explains how a program works. Documentation can be written inside the code or outside the code.
Documentation Can Explain
- What the program does
- Who wrote the program
- When it was created
- How to use the program
- What variables mean
- What procedures do
- What inputs are needed
- What outputs are produced
- Known problems or limitations
17. Internal Documentation
Internal documentation is written inside the program. This usually includes comments.
// Ask the user for their name
name ← INPUT()
// Display a greeting
DISPLAY("Hello, " + name)
18. External Documentation
External documentation is written outside the program.
- A user guide
- A design document
- A README file
- A flowchart
- Pseudocode
- A testing table
- A project reflection
19. Good Documentation Practices
Good documentation should be:
- Clear
- Accurate
- Easy to read
- Updated when the code changes
- Helpful but not excessive
Weak Comment
// Add 1
count ← count + 1
Better Comment
// Count another correct answer
count ← count + 1
20. Testing Table Example
A testing table helps organize test cases.
Example program: A program determines whether a number is positive, negative, or zero.
| Test Number | Expected Output | Actual Output | Pass/Fail |
|---|---|---|---|
| 5 | Positive | Positive | Pass |
| -3 | Negative | Negative | Pass |
| 0 | Zero | Positive | Fail |
The failed test shows that the program needs debugging.
21. Debugging Process
- Identify the Problem: Find out what is not working.
- Reproduce the Error: Run the program again with the same input to see if the error happens again.
- Locate the Error: Look at the part of the code related to the problem.
- Fix the Error: Change the code.
- Retest the Program: Run the program again to make sure the problem is fixed.
- Test Other Cases: Make sure the fix did not create a new problem somewhere else.
22. Debugging Example
Problem
The program should display Pass when the grade is 70 or higher.
Incorrect Code
IF grade > 70
{
DISPLAY("Pass")
}
ELSE
{
DISPLAY("Fail")
}
Test Case
| Grade | Expected Output | Actual Output |
|---|---|---|
| 70 | Pass | Fail |
Bug
The condition uses > instead of >=.
Corrected Code
IF grade >= 70
{
DISPLAY("Pass")
}
ELSE
{
DISPLAY("Fail")
}
23. Program Requirements
Before testing a program, programmers should understand the program requirements. Requirements describe what the program is supposed to do.
Example Requirements
A quiz program should:
- Ask the user five questions
- Keep track of the score
- Display the final score
- Display a passing message if the score is 70 or higher
24. Testing Against Requirements
| Requirement | Test |
|---|---|
| Ask five questions | Run program and count questions |
| Track score | Answer questions correctly and incorrectly |
| Display final score | Check final output |
| Display passing message | Test score above and below 70 |
Testing against requirements helps make sure the program solves the correct problem.
25. Peer Review
Peer review means another person looks at your code and gives feedback. A peer reviewer may find mistakes the original programmer missed.
Peer Review Can Check
- Does the code work?
- Is the code easy to read?
- Are variable names clear?
- Are comments helpful?
- Are there repeated sections that could be simplified?
- Does the program meet the requirements?
26. Code Readability
Code should be easy for humans to read, not just for computers to run.
Good Code Readability Includes
- Clear variable names
- Consistent indentation
- Helpful comments
- Simple structure
- Avoiding unnecessary repeated code
Poor Variable Name
x ← 85
Better Variable Name
studentGrade ← 85
The second version is easier to understand.
27. Debugging Strategies
- Read error messages carefully
- Check spelling and punctuation
- Test one part at a time
- Use print statements
- Trace variable values
- Use test cases
- Ask another person to review the code
- Compare actual output to expected output
- Take a short break and return with fresh eyes
28. Common Student Debugging Mistakes
- Changing too many things at once
- Not reading the error message
- Forgetting to save the file
- Not retesting after fixing the code
- Testing only one input
- Assuming the program works because it ran once
- Ignoring boundary cases
- Removing comments that explain important logic
A good programmer fixes one issue at a time and tests carefully.
29. Documentation Example
Program Header Example
// Program Name: Grade Checker
// Programmer: Student Name
// Date: May 14, 2026
// Purpose: This program checks whether a student passed based on a grade.
Procedure Comment Example
// Procedure: checkGrade
// Purpose: Determines whether the grade is passing or failing
// Parameter: grade - the student's numeric grade
// Return: "Pass" if grade is 70 or higher, otherwise "Fail"
Good documentation helps others understand the program faster.
30. AP CSP Connection
In AP Computer Science Principles, students are expected to understand that:
- Programs should be tested with different inputs
- Errors can be found through testing and debugging
- Programs may contain syntax, logic, or runtime errors
- Programmers should use test cases
- Documentation helps explain program purpose and behavior
- Clear code is easier to debug and maintain
- Programs should be checked against their requirements
31. Key Vocabulary
| Term | Meaning |
|---|---|
| Bug | An error or mistake in a program |
| Debugging | Finding and fixing errors in code |
| Testing | Running a program to check if it works correctly |
| Test Case | A specific input and expected output used to test a program |
| Syntax Error | An error caused by breaking language rules |
| Logic Error | An error where the program runs but gives the wrong result |
| Runtime Error | An error that happens while the program is running |
| Documentation | Written explanation of how a program works |
| Comment | Text in code that explains the program and is ignored by the computer |
| Boundary Case | A test case at the edge of a condition |
| Peer Review | Having another person review your code |
32. Summary
Debugging and testing are important parts of programming. Debugging helps programmers find and fix errors, while testing helps confirm that the program works correctly.
Good programmers do not just write code. They test their code, document their work, and improve their programs over time.
Testing with normal, boundary, and invalid inputs helps make programs stronger and more reliable. Documentation and comments help programmers and users understand the program’s purpose and design.