Some Useful Debugging Tricks

1
Some Useful Debugging Tricks

• Design
• Incremental Coding Review
• Stubs
• Drivers

2
Design Before Debugging

• Nothing makes debugging easier than a carefully
  designed program!
• Designing your program is a process.
• Identify the objects and classes involved
• Create inheritance and containment diagrams that
  represent the relationships between your objects.
  Keep in mind that you can revisit this later.
• Write pseudocode for your complicated methods.
• Hand-simulate your pseudocode! This is very
  important.
• Once you have your program designed, it will be
  much easier to figure out where to start coding.

3
Incremental Coding

• Throughout the course weve encouraged
  incremental coding
• Its a terrible idea to try to code your whole
  program and then attempt to debug it.
• Instead, try to code one of the more basic
  methods of a program, make sure it works, and
  then move on.
• For example, In LiteBrite, you might have coded
  your Palette first, because it works
  independently of your other classes. If you had
  tried to code your Grid, you would have run into
  trouble since it depends on the Palette class.
• Unfortunately, its almost never this easy. In
  more complicated programs, there are often many
  interdependencies among classes.
• How do we incrementally code these complex
  programs?
• Stubs and Drivers!

4
The Problem

• Lets look at a problem that might occur in
  Swarm.
• First you decide to code your Bee class.
• However, you cant test it, because the Bee s
  react method needs to use the getBehavior()
  method in the BehaviorHolder, which you havent
  written yet!
• Furthermore, react() wont be called because you
  havent set up your MouseListener yet.
• We can use a stub to solve the first problem and
  a driver to solve the second.

5
Stubs

• A stub is a really simple concept. Its a
  placeholder method that does something trivial.
• Could simply use System.out.println to say I was
  called
• Could return a dummy value.
• So, in this case, we can write a stub for the
  method getBehavior() in the BehaviorHolder class
  that does something trivial, like always return a
  new DoNothingBehavior.
• For testing, your BehaviorHolder could look like
  this
• public class BehaviorHolder
• public BehaviorHolder()
• //empty for the moment
• public Behavior getBehavior()
• return new DoNothingBehavior()

6
Drivers

• Drivers are the opposite of stubs.
• You use a stub when the method youre testing
  calls another method you havent defined yet
• You use a driver when the method youre testing
  will be called by a method that you havent
  written yet.
• If we havent set up a MouseListener yet, how can
  we simulate the Bee being clicked on?
• Easy! Have your MainPanel/Swarm call react() on
  the Bee it created at startup.
• So, somewhere in the constructor for your
  MainPanel/Swarm, you might have the following
  lines of code
• Bee queenBee new Bee(_dp)
• //other code elided
• //simulate mouse click!
• queenBee.react()

7
Testing

• So what will happen when you run this code?
• First, you might want to test the general
  functionality of your Bee. In other words, dont
  call react() just yet.
• Hopefully, your Bee should appear and fly around
  randomly.
• Now add in the call to react().
• If your react() method works, the Bee should
  appear, but should not be moving anymore!
• This is because we simulated a click on the Bee
  while the current behavior was a
  DoNothingBehavior.
• Arent stubs and drivers great !

8
When Things Go Wrong

• Stubs and drivers can still be useful even after
  youve written some code.
• Suppose youve got Swarm working. You decided,
  for extra credit, to try to make your Bees change
  color.
• So you create a Timer, which calls a
  changeColor() method on a Bee at regular
  intervals. But things arent working
• What do you do? You make your changeColor()
  method into a stub by dummying up the code
  thats already there.
• Simply comment out the code and add a
  System.out.println(changeColor called!)
• Now run your program. If you dont see that text
  printed out to the shell, you know your timers
  not working correctly!
• Otherwise, the problem must have been in the code
  you commented out.
• Simple, huh? Arent stubs and drivers great?