Lecture 2b: Effective Debugging, JUnit

I. Effective Debugging


This lecture will give you an introduction to debugging techniques and terms used in most IDEs (like Eclipse and Visual Studio) and how you can leverage it to your advantage.

Random geek nonsense:
The term debugging came about in the late 1940s and early 1950s with a lot of mumble jumble but it really came about when a developer was trying to "debug" something for days and ended up solving the problem after squashing a bug in her book... hence the term "de-bug"... but that's a rumor from all accounts.

Let's first look at how you can start the topic of debugging by identifying the process (thanks to Wikipedia):

The rest of the sections will discuss each step.

Recognizing that a bug exist

Admit it, no code is perfect! Your code may break... ok, with maybe the exception of the "Hello World!" example and other ridiculously small programs. But really... the hardest part is recognizing that a bug exists. There are many ways to discover that fact. Here are some examples of techniques:

More on this topic can be uncovered when you delve deeper into software engineering... but just know Unit and Regression testing for now. Read into the Pragmatic Programmer for more details on some of these techniques. We only covered isolated code here.

Isolating the source of and identifying the cause of the bug

So you know there is a problem... now the fun starts. You can trace down where the problem is using a few techniques:

One of many ways to track down, in a general sense, where the problem is to look at the UML or other diagrams and determine which "block" of code associates with the functionality. Take our example of the car design. If the window won't go down, you know that the problem must be either in the door object or the window pane object.

Give output statements saying what different variable's values are. For example, the variable i is in suspicion. What you do is right before you use it do System.out.printf("i = %d\n", i);

Rubber Ducking
Explain your idea and process to a friend in detail... they don't have to listen, just smile and nod will do. This forces you to explain your whole process, making it have to make sense... which reveals mistakes.

Process of Elimination
Incrementally go through your code and test things one at a time, you'll have to get to the problem when you scratch everything off one at a time... or you're just formulating your "units" wrong.

Element of Surprise
Don't assume something works... prove it! This is more specific than unit testing in that it breaks things down to "units". This talks about anything in your code, do it line at a time. The depth of rigor is your choice... don't be surprised if int i = 0; is where it breaks (if you are out of memory this won't work).

Determining and applying a fix to the bug

Determining a fix can be anything for each problem... but always remember to go back and test it. It may end up not working or breaking something else.

How can Eclipse help me?

I'm glad you asked because Eclipse can make life so much easier for you. It will help by showing you every step of the process... where a step is a line of code.

So first, let's start debugging:

This shows what happens when you press on the arrow button next to the spider button. You get to choose the program that you want to debug.

If your program just does nothing but output... it just zips through like nothing is different this time... but why? Because you need to tell it where to stop ... which is a breakpoint. In the margin, double click on where a line would start and you would have created a breakpoint:

Setting a breakpoint.

This time it will ask you for a perspective change, which will bring you into the debug perspective in Eclipse. Answer yes.

Answer YES to perspective change.

In the new perspective you will be faced with windows. The windows are labeled in the next screenshot:

Notice that the only two new windows that are of interest are the stack and the variables window.

This essentially tells you, when the program is paused at that breakpoint what the variables are like and what depth are the function calls. A few other buttons also show up above the debug window:

You can keep advancing the stack until you get to the bottom... this shows the recursion that just keeps going deeper.

It even helps you by pointing out in yellow highlight that your condition finally became true. Notice how the stack has a bunch of Fibonacci functions called... this is the memory stack action that I was talking about in class.

So now that you are done debugging... you want to go back to the programming view... how? Just switch perspectives by clicking on the Java perspective:

II. JUnit

JUnit slogan: Keep the code clean, keep the bar green!

To get you all acquainted, let's all do the following tutorial's step 2, 4 and 5: http://open.ncsu.edu/se/tutorials/junit/.

Now take your Assignment 1 and build a JUnit test for it (refer to step 5 of the above link for the appropriate assertion statement to use).

Video Apples to Apples entries

Green Apple: Powerful (Moderator: Anthony)

Red Apples:

Anthony: Re: MOONSPEAK LOL (Automatic disqualification, he's the moderator)
Dom: 1) Powerthirst (intro), 2) Powerthirst, again (Counts as one submission)
Sal: Techno Viking (Question to Sal: This can't be in America, what country is this? It looks like Linköping Sweden.)
Jasper: Dragon (Trogdor from StrongBad Email)