Debugging and Testing Java Programs

Debugging is the process of finding and removing errors, or 'bugs,' from a computer program. Testing is the process of running a program to check whether it behaves as expected. In Java, these two skills are essential because even a tiny mistake — a missing semicolon, a wrong variable name, or a logic error — can make your entire program produce incorrect results or crash entirely.

The most straightforward debugging technique that beginners learn is using print statements. A print statement is a line of code that outputs a message to the console (the text-based screen where a program's output appears). In Java, you use System.out.println() to print a message. For example, if you want to check the value of a variable called 'score' at a certain point in your program, you can add: System.out.println("The score is: " + score);

When the program runs, it will print 'The score is: 42' (or whatever the current value is) to the console. This lets you see what is happening inside your program as it executes. You can add multiple print statements at different points to trace the flow of execution and see which parts of the code are running and in what order.

Why does this matter? Imagine you wrote a program that calculates the total cost of items in a shopping cart. The program runs, but the final price is too high. Without any way to see what is happening inside the program, you are just guessing. But if you add print statements to check the price of each item before and after a discount is applied, you might discover that the discount is being applied twice, or that a variable is not being reset correctly each time a new item is added. That is the power of print statements: they give you visibility into the hidden behaviour of your code.

Simple debugging goes beyond just printing values. It involves a systematic approach:

Another simple debugging technique is 'commenting out' code. This means turning a line or block of code into a comment by putting two forward slashes // at the start. The Java compiler ignores commented code, so it will not run. By temporarily removing parts of your code, you can check whether a specific section is responsible for the error. For example, if your program gives an incorrect calculation, you can comment out the line that applies a discount and see if the total becomes correct again. If it does, then the bug is likely in the discount logic.

A related concept is the 'stack trace,' which appears when a Java program crashes due to an exception (an unexpected error event). The stack trace is a list of method calls that were active when the error happened. It shows the exact line number in your code where the error occurred, plus the chain of methods that led to it. Reading a stack trace is a critical debugging skill. For example:

Exception in thread "main" java.lang.ArithmeticException: / by zero at Calculator.divide(Calculator.java:15) at Main.main(Main.java:10)

This tells you: an ArithmeticException (dividing by zero) happened inside the divide method of the Calculator class, at line 15 of Calculator.java, and the divide method was called from the Main class's main method at line 10. You can go directly to line 15 of Calculator.java to see what is wrong.

Testing, on the other hand, is about verifying that the program behaves correctly under different conditions. The simplest form of testing is manual testing: running the program with different inputs and checking the outputs against expected results. For example, if you write a method that calculates the area of a rectangle, you should test it with length = 5 and width = 3 and check that the result is 15. You should also test edge cases, such as length = 0 (which should give 0) and negative values (which should be handled gracefully or rejected).

The key takeaway is that debugging and testing are complementary. Testing identifies that a problem exists, while debugging finds the specific cause of that problem and fixes it. Both skills are fundamental for any programmer, and the 1Z0-811 exam tests your ability to apply them using print statements and basic reasoning.

An IT professional — let us call her Priya — is a junior Java developer at a small e-commerce company. She has just written a method that calculates the final price of an order after applying a 10% discount for orders over £100. The method takes the original total as input and returns the discounted price. Priya runs a quick test with an order total of £200. She expects the result to be £180 (200 minus 10% of 200). But the program prints £190. Something is wrong.

Priya does not panic. She opens her Java code in an editor and looks at the method. Here is what she sees:

public double calculateDiscountedPrice(double total) { double discount = 0.10; if (total > 100) { double discountedPrice = total - (total * discount); } return discountedPrice; }

Priya adds a print statement right after the discount calculation:

System.out.println("Total before discount: " + total); System.out.println("Discount amount: " + (total * discount)); System.out.println("Discounted price after calculation: " + discountedPrice);

She runs the program with total = 200. The console prints:

Total before discount: 200.0 Discount amount: 20.0 Discounted price after calculation: 180.0

Wait — that looks correct. But why did the method return 190? Priya then adds a print statement just before the return:

System.out.println("Returning value: " + discountedPrice);

She runs it again. This time the console shows:

Total before discount: 200.0 Discount amount: 20.0 Discounted price after calculation: 180.0 Returning value: 0.0

This is a classic trap. Priya realises that the variable discountedPrice is declared inside the if block, so it only exists within that block of code (between the curly braces). Outside the if block, the variable is not defined. The return statement at the end of the method is trying to return a variable that does not exist in that scope. In Java, this causes a compilation error, but her environment might have a default error handling that returns 0.0. The print statement reveals the truth: the variable inside the if block is correct, but the method returns a different, non-existent variable.

Priya applies the fix: she declares discountedPrice before the if block, initialises it to total, and then updates it inside the if block if the condition is met. She also removes the print statements. She runs the test again with total = 200 and gets the correct answer: 180.0.

In a real business scenario, Priya would also write a few more test cases: total = 50 (no discount, should return 50), total = 100 (no discount because condition is > 100, not >=), and total = 0 (should return 0). This ensures her fix works for all edge cases. She might also integrate her code into a build pipeline that automatically runs these tests every time she saves her code, but for the 1Z0-811 exam, the focus is on manual debugging with print statements and simple reasoning.

Priya's story shows exactly what IT professionals do daily: they write code, test it, find bugs, add print statements to understand what is happening, fix the bug, and verify the fix. It is a structured, methodical process — not random guessing.