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):
- Recognize that a bug exists
- Isolate the source of the bug
- Identify the cause of the bug
- Determine a fix for the bug
- Apply the fix and test it
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:
- Unit testing: A test that tests every individual "unit" of a code, whatever that unit is. JUnit is an example of this, utilizing the xUnit framework.
- Regression testing: Testing for regression bugs, bugs that occur in previously working code after something new is added. This usually happens when software goes through versioning.
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);
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:
- Resume: get the program running until it hits another breakpoint or reaches the end, when it pauses at that point again.
- Step Into: allows you to move the program forward by only one line... but jump into any function that is called.
- Step Over: same as Step Into except you don't go into the function that is called, just going over that line in the current function.
- Step Return: if you are in a function that you stepped into, this can get you back to the calling function... assuming that it didn't crash while finishing this function's operations.
- Drop to Frame: you can select a function in the function stack and execute until you get back to that frame.
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:
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).
Green Apple: Powerful (Moderator: Anthony)
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)