Skip to content

c. Practical Examples

Testing, Debugging and Maintainability

These examples use a light I do - We do - You do model. Students should attempt the reasoning first, then compare with the hidden model response.

Example 1 - I do: Improving naming and comments

Starting code

int x = 4;
double y = 12.50;
double z = x * y; // multiply x by y
Console.WriteLine(z); // print z

Try first

Identify:

  1. one naming problem
  2. one weak comment
  3. one improvement you would make first
Teacher walkthrough
  • The variable names x, y and z do not explain purpose clearly.
  • The comments are weak because they mostly repeat what the code already shows.
  • A stronger version would use meaningful names and comments only where they add value.
One possible improved version 
int ticketQuantity = 4;
double ticketPrice = 12.50;
double totalCost = ticketQuantity * ticketPrice;

Console.WriteLine("Total cost: $" + totalCost);

Focus: Code should be readable even before comments are added.

Example 2 - We do: Choosing boundary test data

Scenario

A solution accepts a booking time only if it is from 15:00 onward.

Try first

Choose three useful test values:

  1. one just below the boundary
  2. one on the boundary
  3. one just above the boundary
One possible model response
  • 14:59
  • 15:00
  • 15:01
Why these work

Boundary testing checks what happens just outside and just inside the allowed limit, not just in the middle of the valid range.

Focus: Good test data is chosen deliberately, not randomly.

Example 3 - We do: Expected result versus actual result

Scenario

A discount formula should calculate:

finalPrice = price - (price * discountRate)

The developer accidentally writes:

finalPrice = price - discountRate

Try first

If price = 20.00 and discountRate = 0.10, decide:

  1. what the expected result should be
  2. what the incorrect actual result would be
  3. what this tells you about the error type
One possible model response
  • Expected result: 18.00
  • Incorrect actual result: 19.90
  • This suggests a logic error because the code can run, but the formula is wrong.

Focus: Comparing expected and actual results is how testing reveals that something is wrong.

Example 4 - You do: Choose a debugging technique

Scenario

A program crashes when trying to open a file that may not exist.

Your task

Decide:

  1. would a breakpoint help, a debugging statement help, or both?
  2. what would you look for while debugging?

Retrieval Prompt

Explain your answer in terms of what information the technique reveals, not just its name.

Example 5 - You do: Retrieval grid

Complete the table from memory.

Term What does it mean? Why does it matter?
Camel case
Internal documentation
Boundary value
Expected result
Breakpoint
Logic error

Study Tip

Retrieval is more effective when you connect the term to a real programming situation.