Lab 5: Writing Main Classes and Finding Bugs
1 Lab Objectives
Show you how to write Main classes and main methods.
Give you practice tracking down errors in code
As we get into the last two (and most complicated) assignments, I’ve heard requests for more practice at finding errors in code. This lab combines practice finding code errors (through writing tests, hand-tracing, and using the debugger), with showing you how to set up your programs to start automatically when you run them.
If you’ve not seen, or need practice with, the debugger, we recommend you switch over to that part of the lab (Using the Debugger) with 20 minutes to go, if you haven’t already gotten there.
The context for this lab is writing a simple voting system. There are two starter classes: VoteBooth.java gives you a user interface through which you can cast votes and see election results, while VoteData.java stores all the data about an election (the names of candidates and the votes that have been cast).
To start up the voting system, make a new VoteBooth object, and call the screen method on it. If we were demo-ing this in lecture using DrJava, we would type
> VoteBooth v = new VoteBooth(); |
> v.screen() |
Now, you can cast votes and ask for election results.
2 Adding a Main Class and main Method
Up until now, nothing has "happened" when you run one of your programs. We have relied on test cases to run your code. In a realistic system, testing and running the system are separate activities. For the voting system, we would like the screen to come up automatically when we run the program.
Create a class called Main. In it, put a method with the following header:
public static void main(String[] args) { |
// what to do on startup goes here |
} |
Inside the main method, you can write whatever code you want. When you run the program, Java runs the main method of the Main class automatically. Set this up, run your program, and watch the screen start up.
3 Tracking Down Bugs
With your screen running, try (1) voting for Husky then (2) asking for the winner (by entering *W). Notice that the reported winner is Gompei. Now you have to figure out why.
The goal here is not just to find the error and make the code run properly. The goal is to practice techniques for finding errors. Even if you visually spot the error quickly, try using the techniques given below to "discover" it afresh. This will teach you which techniques work well in different situations.
In general, there are three strategies to take when you realize your code isn’t working:
Write some test cases to make sure all relevant methods are working properly (in isolation of each other).
Trace through the code by hand, tracking the values of all variables as each method runs (to understand what your method is actually doing).
Use a tool called a debugger to help you see how the code is evaluating.
Working through test cases as much as you can is much better professional practice: it leaves you with a set of tests that can continue to check your code as you add features, make modifications, and so on. Working through tests also forces you write small, focused methods, rather than complicated methods with lots of variables. This is also very good professional practice.
Writing tests should be how you identify which specific method in a more complex computation is going wrong. Once you’ve identified the method and a couple of specific inputs that show the erroneous behavior, you may need to move on to one of the other techniques to locate the mistake within the method (though you can often just spot the error directly at this point).
3.1 Adding Some Tests
When you are trying to find the bugs in a program that has a user interface, remember that the core of the problem is very likely in the methods that operate on the underlying data structure (here, VoteData.java).
Look at the methods that get called as part of computing the winner through the user-interface. Use tests to identify the method or methods that are producing the wrong answer as part of this computation.
3.2 Tracing a Specific Test Through Code
Now that you have a specific test case that fails, try evaluating the code by hand on the easiest/shortesst of your failing test cases. On a piece of paper, write down the names of all the variables and their current values. As you walk through the code step by step, update the variable values on your paper, looking to see when one of the values is other than what you expected. This can often help you find the error.
3.3 Using the Debugger
A debugger is a tool that helps you with the process of tracing through your code. You can set up a debugger to walk you through your code statement by statement (seeing how the values change). You can tell it to run to a certain point and then start going step-by-step (called setting breakpoints), and other handy options.
Since this lab was a late request by students and staff, we didn’t have a chance to write out custom instructions for this voting problem withiin each of the three supported environments. However, we provide links here to tutorials on each one (the Eclipse and IntelliJ tools are much more sophisticated, since they support larger-scale, professional programming practice).
Grab a tutorial, grab a friend, cluster up and have the staff show you how these tools work. Try them out on the voting system, or whatever code is in the tutorial. You can always use the voting system for additional practice later if you wish. (The voting code also contains a broken method called longestStreak which gives you another option to practice debugging.)
4 What to Turn In
You don’t need to turn in anything for lab this week, seeing as you wrote little to no code for it.