First, create a lab10 directory:
$ cd cs190m $ mkdir lab10 $ cd lab10
Then, download Lab10.java and Lab10JUnit.java into the folder you just created.
Bugs are a more elusive manifestation of human error in programming. Compile-time errors are easy to detect and usually just as easy to fix. However, run-time bugs don't appear until during execution and may not become apparent until long after they actually appear. Fortunately, there are tools to help finding run-time bugs easier. DrJava has a built-in debugger that we can use to track down bugs.
Print statements are the simplest method of debugging. Strategic placement of print statements in a program can help with debugging of programs. Debugging programs with prints is simple. First, you determine where in your program that print statements should go; then, you print out relevant data and run your program. By examining your program output, it's possible to determine where the error in your program occurs.
Since print statements are a straightforward method of debugging, placement of prints is not discussed here; instead, it is up to you to determine what places are considered strategic. Print statements can sometimes get messy in larger programs, however. In this case, a debugger can become more useful. The remaining subsections discuss use of debugging tools, particularly within DrJava.
Breakpoints are points that you specify in a program in which to halt execution. When you hit a breakpoint when running your program, DrJava will stop and let you examine the state of your program in the Interactions tab. To set a breakpoint in DrJava, use Ctrl-B. If you did it correctly, then the line should turn red. To use DrJava's debugger, hit Ctrl-D and a new panel with Stack and Threads tabs should appear. Then run the program normally and when execution reaches the breakpoint it will stop and look like the picture below:
In the Interactions panel, whenever a debugging prompt comes up, you can type in Java code to either set variables to a new value or get their old values. This is helpful in determining when a calculation goes wrong. For example, in the picture above, if you wanted to see the value of t, you would just type t into the prompt and hit Enter. You should see "1.0" printed, since you're on the first iteration of the for loop. You can also assign a variable like so: t = 200.0
When you come to a breakpoint, after you look at the state of the program using debugging interactions, you may not want to continue execution until the next breakpoint is reached. Perhaps you are interested in the value of a variable immediately after a statement. The Debugger menu has several commands for the debugger that enable you to execute code step by step, rather than piece by piece. This method is sometimes called tracing.
The debugging commands are as follows:
Notice that there are shortcut keys for all of the mentioned debugger commands. It is highly advantageous to memorize these, since you may end up using them quite often. The image below shows an example of stepping. The debugger originally stopped on the red line; however, after hitting F11 twice, the debugger is two lines below.
Today you'll be examining an implementation of a method in the Lab10 class that estimates pi (π). This implementation intentionally has an error in it. Your job is simply to fix the bug using the Java debugger. For your information, the formula used in the estimation is:
The method takes a single argument, n, which is equivalent to the upper bound of the summation in the formula. This approximation should converge rather quickly, but you'll notice that even with 100,000 iterations, there is a large error in the result. You can see this by running the program.
Unit testing is exactly what it says—testing units of code. In this case, unit is defined by a single, atomic (undividable) group of code. In the case of Java, a unit is a method. Unit testing is often thought as a preventive measure to stop bugs from ever appearing in your code to begin with. A more extensive article on unit testing can be found here.
Note: DrJava's JUnit API may be slightly different if you decide to use another IDE. If this is the case, you should visit the JUnit website.
JUnit tests are grouped by classes; often times, one JUnit test class corresponds to one implemented class in your code. To see what a JUnit test class looks like, click "File" and then "New JUnit Test Case". It will prompt you for a name for the class; type in Lab10Test.
Inside the class you should see a method called testX.
We can do a trivial test to see if Java's arithmetic is working. Inside the method, insert the line:assertEquals("Addition", 5, 3+2);
This line tests to see if the right most value (the result of 3+2) is equal to the expected value in the middle. The string is simply a description that tells you what assertion failed. To run the test, click the "Test" button next to the "Run" button. It will prompt you to save all of your files (click yes) and the run the test. You should see output like this:
All tests completed successfully.
Lab10Test
testXNotice that testX is colored bright green. This simply shows that the test passed. If the test fails, it will be colored red instead, with additional information. To see what it looks like, simply change one of the values:
1 test failed:
Lab10Test
testX
File: /homes/dytang/cs190m/lab10/Blah.java [line: 17]
Failure: Addition expected:<5> but was:<6>Notice that assertEquals compares two integers. You can also use assertTrue and assertFalse (which take a String and boolean) as well, to check conditions.
Inside the Lab10JUnit file that you downloaded, there is a simple method that calculates an exponent, given an integer base and integer exponent. Your task is to determine proper unit tests to test this function (hint: there should be at least three, what are the different cases/types of exponents?). If your unit tests uncover errors with the program, then you should correct the method until all of your tests pass.
To turn in your lab:
$ cd ~/cs190m/lab10 $ turnin -v -c cs190m -p lab10 *.java
Many of you will probably run across problems while programming at some point during a lab. If that's the case, here are the resources you should use, in order:
Lab created by: Daniel Tang