Programming 1: Testing, Debugging and Maintenance

Lesson Overview

Design tests, use debugging evidence and make small maintenance changes without breaking behaviour.

Portfolio focus: Write a test table for a mark validator.

ConceptTesting

Run fileTestingDebuggingAndMaintenanceDemo.java

Baseline-1 valid? false 0 valid? true 40 valid? true 100 valid? true 101 valid? false

Evidence3 tasks

Starter: think before typing

Before running this testing example, find the line where the main idea becomes active. Write a prediction: what must already be true for that line to work, and what should be different after it runs? The checked run ends with `-1 valid? false 0 valid? true 40 valid? true 100 valid? true 101 valid? false`; predict how the focus line helps produce that evidence.

Learning Objectives

Distinguish syntax, execution and logic errors.
Design normal, boundary and invalid tests.
Use debugger output or print tracing carefully.
Describe a maintenance change and regression risk.

Learning Outcomes

By the end of the lesson, you can distinguish syntax, execution and logic errors.
By the end of the lesson, you can design normal, boundary and invalid tests.
By the end of the lesson, you can use debugger output or print tracing carefully.
By the end of the lesson, you can describe a maintenance change and regression risk.

Why this idea exists

Testing grew from a simple truth: running a program once is not evidence that it works. As software became more important, programmers needed systematic ways to expose faults and protect existing behaviour.

Debugging is investigation, not guessing. A debugger, trace output or failing test should narrow the gap between what the programmer believed and what the machine actually did.

Maintenance is the normal life of software. Most professional programming is changing existing systems, so clear tests, small changes and regression awareness are degree-level habits from the beginning.

Deep dive

Mechanism in this example

The important mechanism is visible around `return score >= 0 && score <= 100;`. Read it as a concrete move in the program, not as decorative syntax: identify what value, object, branch, call or boundary is being created at that point.

Design pressure

Failure mode to watch

For Testing, Debugging and Maintenance, deliberately disturb the assumption behind `return score >= 0 && score <= 100;`: use an awkward value, missing input, wrong order of calls or boundary case. The useful question is how that disturbance exposes a weakness in the testing design.

Extension step

Extend the example by doing this: Fix a seeded bug. The point is to make one small change that forces you to revisit the concept, rather than adding unrelated features.

Portfolio standard

The portfolio note should not repeat the lesson wording. It should show the edited code, the run result, and your own explanation of this evidence: record before/after evidence in portfolio notes.

Lesson visual

Photographic scene of a bug report, test checklist, failing console output and a debugger paused on a Java line.Download visual

Type this and run it

Create TestingDebuggingAndMaintenanceDemo.java, type the program, and run it before changing anything. This section is about reproducing the checked baseline.

public class TestingDebuggingAndMaintenanceDemo {
  public static void main(String[] args) {
    int[] scores = {-1, 0, 40, 100, 101};
    for (int score : scores) {
      System.out.println(score + " valid? " + isValidScore(score));
    }
  }

  static boolean isValidScore(int score) {
    return score >= 0 && score <= 100;
  }
}

Build and run it with:

javac TestingDebuggingAndMaintenanceDemo.java && java TestingDebuggingAndMaintenanceDemo

Expected baseline: -1 valid? false 0 valid? true 40 valid? true 100 valid? true 101 valid? false

Run the code in your browser

Use the editor as an experiment surface. First run the checked version, then make one small change to the part of the program that demonstrates testing and compare the new behaviour with the reference output.

Editable Java code

public class TestingDebuggingAndMaintenanceDemo {
  public static void main(String[] args) {
    int[] scores = {-1, 0, 40, 100, 101};
    for (int score : scores) {
      System.out.println(score + " valid? " + isValidScore(score));
    }
  }

  static boolean isValidScore(int score) {
    return score >= 0 && score <= 100;
  }
}

-1 valid? false
0 valid? true
40 valid? true
100 valid? true
101 valid? false

Line-by-line explanation

Read the code as a sequence of responsibilities. The focus line for this lesson is return score >= 0 && score <= 100;; the surrounding lines prepare it, use its result or make the behaviour observable.

public class TestingDebuggingAndMaintenanceDemo {

This names the runnable class for the Testing, Debugging and Maintenance example, giving the compiler and JVM one clear unit to build.

public static void main(String[] args) {

This is the program entry point. In Testing, Debugging and Maintenance, it keeps the demonstration of testing in one traceable starting script.

int[] scores = {-1, 0, 40, 100, 101};

This introduces scores as named state for Testing, Debugging and Maintenance. Later lines can read, update, pass or print that specific value as evidence.

for (int score : scores) {

This starts repetition in Testing, Debugging and Maintenance. Check the initial value, the stopping condition and the update on each pass.

System.out.println(score + " valid? " + isValidScore(score));

This prints score + " valid? " + isValidScore(score) as the observable evidence for Testing, Debugging and Maintenance. The output lets the learner check whether the testing idea behaved as predicted.

}

This closes the innermost Testing, Debugging and Maintenance block, so the immediately preceding method, branch or loop has finished.

}

This closes the outer Testing, Debugging and Maintenance structure, returning the reader to the surrounding class or file.

static boolean isValidScore(int score) {

This starts isValidScore, a named Testing, Debugging and Maintenance operation. Its parameters describe what information comes in; its body decides what work is done.

return score >= 0 && score <= 100;

This sends a Testing, Debugging and Maintenance result back to the caller, so the surrounding code can use the answer.

}

This closing brace number 3 completes another layer of the Testing, Debugging and Maintenance source structure Java has been checking.

}

This closing brace number 4 completes another layer of the Testing, Debugging and Maintenance source structure Java has been checking.

Worked example

From code to explanation

Problem: Use Testing, Debugging and Maintenance to complete a small portfolio-quality step: Write a test table for a mark validator.

Method: Locate the line `return score >= 0 && score <= 100;`, explain the exact role it plays, then decide what you would change to extend the example without changing the whole program.

Reveal worked answer

The checked run should produce `-1 valid? false 0 valid? true 40 valid? true 100 valid? true 101 valid? false`. A strong answer links the result back to testing: what was created, selected, stored, called or protected, and why that matters for the portfolio task.

Trace the program

Before: Before the key operation, identify the relevant value, object, branch or resource that the testing concept depends on.

During: Trace `return score >= 0 && score <= 100;` as the Testing, Debugging and Maintenance example executes. Say whether that operation creates data, checks a condition, calls behaviour, stores information or crosses a boundary.

After: Compare the run with the expected evidence: `-1 valid? false 0 valid? true 40 valid? true 100 valid? true 101 valid? false`.

Change: Now fix a seeded bug, run again, and explain the smallest reason the behaviour changed.

Common misconception

A common mistake in testing, debugging and maintenance is treating the example as a finished answer. For testing, the important question is narrower: which operation carries the idea, what does it make possible, and what would break if you changed it carelessly?

Quick checks

1. In this Testing, Debugging and Maintenance example, what is the best reason to focus on `return score >= 0 && score <= 100;`?

It is the only line where punctuation matters.It is where the code demonstrates testing in a concrete way.It can be ignored as long as the final page looks correct.

2. Which evidence is strongest after you edit and rerun this example?

The edited code, the run result `-1 valid? false 0 valid? true 40 valid? true 100 valid? true 101 valid? false` or changed output, and a short explanation of the decision.Only a screenshot of the page after pressing Run.Only the final answer, with failed attempts removed.

How to study this lesson

For Testing, Debugging and Maintenance, predict how testing changes the run before you press Run.

Use the first portfolio task as your main edit: Write a test table for a mark validator.

Use the second task as your variation: Fix a seeded bug.

Finish with evidence, not a diary entry: Record before/after evidence in portfolio notes.

Portfolio Practice

Write a test table for a mark validator.
Fix a seeded bug.
Record before/after evidence in portfolio notes.

Final self-check

Can you explain the key operation?

Explain the line identified in the quick check in one or two sentences. Your answer should say what it does before the output -1 valid? false 0 valid? true 40 valid? true 100 valid? true 101 valid? false appears.

Can you justify the portfolio evidence?

Your evidence should include the original run, one edited run, and a short note explaining how the edit affected testing.

Study route

Practise testing by predicting the Java example, typing it, running it in the browser, tracing the result and saving portfolio evidence.

Next, move into File I/O and Persistence and carry forward one improvement from this lesson into the next program.