Instant Eclipse Application Testing How-to

Go to http://openjdk.java.net/install/index.html and find a command for JDK (not JRE) that corresponds to your version of Linux. For example, I am using Fedora 17, and currently the latest OpenJDK version is JDK 7. So I go to the OpenJDK website http://openjdk.java.net/install/index.html, and then copy and paste the following command to my Terminal (if you are using Ubuntu or Debian, make sure that you copy the right command):

[aspektor@*]$ su -c "yum install java-1.7.0-openjdk"

After the installation is completed you need to make sure that Java is installed. Type [aspektor@*]$ java -version. My output is as follows:

java version "1.7.0_09-icedtea"
OpenJDK Runtime Environment (fedora-2.3.3.fc17.1-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

Open Command Prompt and type C:\> java –version.

If you get something similar to the following output, it means that Java is most probably not installed on your machine:

'java' is not recognized as an internal or external command operable program or batch file,

If you see the output similar to the following, it means that Java is already installed on your machine and you can proceed directly to the Eclipse installation part:

Java version "1.7.0_09"
Java <TM> SE Runtime Environment Standard Edition .....

To install the latest JDK to your Windows machine you will need to go to the Oracle Java website http://www.oracle.com/technetwork/java/javase/downloads/index.html.

There you will see different Java configurations. You will need to download the latest version of Java Platform (JDK) (for now, the latest version is 7u9) as shown in the following screenshot:

Click on Accept License Agreement, choose your architecture, and start downloading.

When the file finishes downloading, open it, click on Next, and you will see a window similar to the following screenshot:

Click on Close, open Command Prompt, and check that you have Java installed, as shown in the following screenshot:

The first step is to download Eclipse from the official Eclipse website, http://www.eclipse.org/downloads.

There are a couple of options available, but as we are going to work with Java, we will need to download Eclipse IDE for Java Developers, which is the second option in the previous screenshot.

Choose your architecture (32 or 64 bit) and start downloading.

If you are installing Eclipse on Windows, please make sure that your Eclipse architecture corresponds to the architecture of JDK. (Installing JDK on Windows shows how to check your Java version.)

When the file finishes downloading, unzip it to the directory of your choice.

Go to the eclipse directory (the one you have just unzipped) and run the Eclipse .exe file.

After a couple of moments you will see a window offering to select a workspace. If you haven't used Eclipse in your machine before, leave the workspace as it is (for example, for me it is /Users/anatolyspektor/Documents/workspace), whereas if you have installed Eclipse and the workspace already exists, rename the workspace to workspace1 or something similar. Click on Ok. It will load the workbench, and then you will be prompted to the Eclipse interface.

Go to File | New | Java Project.

In the Create a Java Project window, name the project as how-to-debug and click on Finish.

Close the Welcome tab and you should see something similar to the following screenshot:

Now expand the how-to-debug project's tree (click on the gray arrow before the project's name) and you will see that there is an src folder. In this folder we will store our classes.

Right-click on the src folder and select New | Class. In the Java class window enter how.to.eclipse as a package, Employee as a name, and check the public static void main(String[] args) option. It will give us a template of the main() method so that we don't have to write it ourselves. Your Java class window should look like the following screenshot:

Click on Finish. You should see that a new class file has appeared in your Package Explorer area under the src folder. The class is populated with the main() method. It should look like the following screenshot:

Now let's fill in the Employee class with a couple of variables such as the position of the employee, employee number, and employee age. Let's also create methods that will set these variables and invoke this information if needed. Finally, let's override the toString() method so that we can see the output of our program.

To show your current position in the debug process, use the Debug view.

In the Debug view, the information is presented as a stack, which starts from the suspended thread and goes down in the format Class.method(params) line: line number, where every upper entry is the more recent position. By double-clicking on the entries, you can navigate back and forth through the debugging steps. Also, if a debugger is terminated, you will see the terminated message in the Debug view right away.

To avoid printing out variable values every time, Eclipse Debug Perspective gives us a wonderful tool called the Variables view.

With the Variables view you can actually follow local and global variables in real time. Moreover, you can change how these values are presented. We will look closer at the Variables view further in the book.

To see a list of all your breakpoints use the Breakpoints view.

The Breakpoint view lists all your breakpoints in the format class [line: line number] – method(types). It also allows you to set up the breakpoint properties, choose which breakpoints should be skipped, remove breakpoints, import/export breakpoints, and navigate directly to the breakpoint in the code. In the next recipes, we will cover how to set up breakpoints with different properties. So if you haven't used breakpoints before, don't worry as we will cover how to use them in detail.

The main area of interaction between your code and the debugger is located inside the class view.

The class view shows the breakpoints and highlights the line you are about to execute. Also, it automatically switches between files when you want to Step Into/Step Over to the other classes.

To see the structure of the class that is currently under inspection of the debugger, take a look at the Outline view.

In the Outline view for Java, you are presented with a tree of variable and method names. The menu above this tree allows you to sort the tree and hide/show different parts of it. Also, by clicking on the variable or method name in the Outline view, you are navigated directly to the definition of this variable or method.

To see the output of your application, use the Console view.

If you look at the top right-hand side of the Console view, you will see a small menu, which gives some extra functionality to the console. The red square button is an option to terminate the thread. For example, it helps when you get into an infinite loop. Some other options in the top menu allow you to clear the console, put a scroll lock, change when to show the console, and open the special Console view (for example, the Maven console or CVS console).

Go to the main() method of the Employee class.

Find andrew.setNumber(123) (on line 110).

Right-click on the line number (if you don't see the line number, click on the left margin of the Employee tab and choose Show Line Numbers as shown in the following screenshot).

Got to line 110, right-click on the margin again, and click on Toggle Breakpoint.

If your breakpoint is successfully set up, you will see the icon right near the line number of the method you wanted to set the breakpoint to. (In our case right near line number 110.)

Now let's run the debugger by clicking on the icon.

If you are asked to switch to Debug Perspective, click Yes.

Click on the Step Into (F5) icon.

Now you are taken to the setNumber() method. If you take a look at the Variables view, there are two lines now: this, which relates to the class variables, and _number, which is a variable of the local method.

Your position is at the if statement evaluating if the number is between certain limits (at line 46).

Click on the Step Into (F5) icon again.

As there is no method to Step Into, the pointer moves one line down; now it's on number = _number.

This line assigns local variables to the class variable.

Click on the Step Into (F5) icon again.

Right now the pointer should be at line 49.

Now let's look at the Variables view again. If you expand this, you will see that the number is highlighted in yellow. This is because the variables have changed their values. See the following screenshot:

This highlighting is very useful, as it allows you to see what variables have changed their values right after it has happened.

Before we use Step Into one last time in this exercise, let's also take a look at the Debug view. Sometimes, when the project is big, it is very hard to determine what is the hierarchical structure of the classes and methods, which you are in at the moment. In our case the Debug view shows that we are in the setNumber(int) method on line 49, and if we look below this line, we see that we came here from the main() method on line 110. See the following screenshot:

Click on the Step Into (F5) icon.

As we have reached the end of the setNumber() method, Step Into makes it return back to the main() method, and the pointer points to the next line (line 111 in our case). Also, the Debug view no longer shows setNumber() in its hierarchy.

We will be using the setPosition() function (on line 30). Let's comment out the if statement in this method. Thus we can set any position we like. The setPosition() function will look like the following:

30. public void setPosition (String _position) {
31.   // if ( Arrays.asList(validPositions).contains(_position)){
32.     position = _position;
33.   //} 
34. }

Go to the main() method and change line 112 to the following:

andrew.setPosition("");

It means that we are providing an empty string as a position.

Set a regular breakpoint to the line 32 (position = _position).

Right-click on the breakpoint and select Breakpoint Properties…. (The last option as shown in the following screenshot.)

In Breakpoint Properties… check the Enable Condition box and in the textbox below type _position.isEmpty().

This means that the breakpoint will be triggered only if _position is an empty string. Note that, we assign __position, but not the class variable position, because at the time the conditional breakpoint is triggered, the position will not be assigned yet.

Click on Ok.

Run the debugger by clicking on the icon.

If you did everything correctly, you should see that the application has stopped on line 32 and is waiting for your actions. It stopped because _position is empty. If _position were not empty, it would skip this breakpoint and proceed with executing the application. Thus, a conditional breakpoint allows us to trigger the breakpoints only for the cases when we really want the program to stop executing.

Now to make the final change to our application so that we can see the difference, first please terminate by clicking on the icon.

Go to line 112 and pass the word tester to setPosition(String). Type the following:

andrew.setPosition("tester");

Click on the Debug button again.

Go to the Debug Perspective, then to the Breakpoints view, and click on the icon. (Add Java Exceptions.)

We will be dealing with NullPointerException. Thus, you need to find it in the list. See the following screenshot:

Click on Ok. Now you should see the NullPointerException breakpoint added in the breakpoint list. If there is any other breakpoint checked, please uncheck it.

Run the debugger.

If you did everything correctly, you should see that the application stopped at line 113, right before throwing an exception.

Click on the Resume icon.

Go to the setAge(int) method definition (on line 60) and set a breakpoint as you usually do it.

Your breakpoint icon should look like this . As you see, this icon is different from the regular breakpoint icon that you have seen before. This is because you have set a method breakpoint.

Run the debugger.

The application has stopped at the first line after the setAge() method definition (on line 61). The breakpoint has been triggered because the method was called by the main() method (as shown on line 111; you can see all this in the Debug view). So every time this method is called, your application will break at the start of the method. This allows you to see what values were passed to the method. This is very useful, but what I find even more useful is setting the breakpoint when the application leaves the method. This will allow you to see how values have changed when the method finished running. Let's try it right now.

Terminate the debugger, go to line 60, and open Breakpoint Properties….

In Breakpoint Properties…, uncheck Method Entry and check Method Exit and click on Ok.

If you did this correctly, you will see that the breakpoint icon has changed again. Now it looks like this: . The arrow in the breakpoint icon shows when the breakpoint should be triggered, at the start or at the end of the method.

Run the debugger.

Go to the Outline view and find the number variable.

Right-click on number and select Toggle Watchpoint. See the following screenshot:

If you go to line 9, you will see that there is a Watchpoint icon instead of a breakpoint. This means that the current variable is being watched. Also, if you want to unset Watchpoint, just double-click on the icon. If you want to set it back, double-click again.

Run the debugger.

The first time when Watchpoint is triggered, the application stops at line 47; that is because the main() method at line 110 called the setNumber() method that assigned a number to the value set by the user.

Click on the Resume icon.

This time the application stops at line 90; that is because the toString() method requested access to the number variable. Note that number was modified the previous time, but this time number was accessed without modification.

Terminate the debugger.

Go to line 9, right-click on the icon, and select Breakpoint Properties….

Uncheck Access and click on Ok.

Now your breakpoint icon looks like this: , which means that Watchpoint will be triggered only when a variable is modified.

Run the debugger.

Once again the application stopped at line 47 because we are modifying the variable.

Click on the Resume icon.

When line 113 is commented out, go to line 47 (number = _number), set a breakpoint, right-click on it, and go to Breakpoint Properties….

Check the condition option.

Focus on the textbox and type the following lines of code:

System.out.println("employee number is "+number+ " but soon will be " + _number);
return false;

In these two lines we are doing two things. We are printing the value of number and _number, and also asking the application to not stop on the breakpoint by returning false.

Click on Ok and run the debugger.

After line 112, please add two more lines:

andrew.setPosition("programmer");
andrew.setPosition("employee");

We need it so that we can call one function several times.

Go to line 31 (if statement of setPosition()) and set a breakpoint.

Right-click on this breakpoint and select Breakpoint Properties….

Check the Hit count option and enter 3 as shown in the following screenshot:

Click on Ok and run the debugger.

If you did everything correctly, your program should stop at line 31. Take a look at the Debug view. Your stack shows that setPosition() was called by the main() method on line 114. Line 114 is the third occurrence of the setPosition() function, which means that the two previous occurrences were skipped.

Click on the Resume icon.

Go to File | New | Other… | Java | JUnit | JUnitTest Case as shown in the following screenshot:

Click on Next>.

In the Package field enter how.to.eclipse.tests.

In the Name field enter EmployeeTests.

Click on Finish. (If you are asked to add JUnit 4 to build a path, click on Ok.)

Go to Java Perspective if you are not already there. See the following screenshot if you forgot how to switch perspectives:

In Package Explorer expand our how-to-debug project.

You should see a couple of new things. First of all, under src | how.to.eclipse.tests there is a new ExmployeeTests class. This is our test class, which we will be using to put our tests for the Employee class. Secondly, there is a JUnit 4 library added to our build path, so that we are able to run JUnit tests.

If we open the EmployeeTests class, we will see that there is one test() method with a method call fail() in it.

Click the icon (Run).

First of all I need to create the Employee object that we will be using throughout all the tests. So in my EmployeeTests class I put:

Employee emp = new Employee();

My next step is to create a test for one of the class variables. I have decided to start with position. As position is set by the setPosition(String) method, this will be the method that I will be passing values to. After setting the position, I will be checking if the tests have been passed by comparing the expected position value with emp.getPosition(). In my comparison I will be using some of the JUnit assert methods.

I created a @Before method that assigns a position to the tester before every test is executed.

I created five tests to check the following:

My EmployeeTests class looks like the following:

1.  package how.to.eclipse.tests;
2.
3.  import static org.junit.Assert.*;
4.  import how.to.eclipse.Employee;
5.  import org.junit.*;
6.
7.  public class EmployeeTests {
8.  Employee emp = new Employee();
9.
10. /**
11. * Before every test this method sets position to "tester"
12. */
13. @Before
14. public void setUp() {
15.     emp.setPosition("tester");
16. }
17.
18. @Test
19. public void testEmployeeNotNull(){
20.     assertNotNull(emp);
21. }
22.
23. @Test
24. public void testPositionValid(){
25.     emp.setPosition("engineer");
26.     assertEquals("engineer", emp.getPosition()); 
27. }
28.
29. @Test
30. public void testPositionNull(){
31.     emp.setPosition(null);
32.     assertFalse(emp.getPosition().equals(null));
33. }
34.
35. @Test
36. public void testPositionEmptyString(){
37.     emp.setPosition("");
38.     assertTrue(emp.getPosition().equals("tester"));
39. }
40.
41. @Test
42. public void testPositionInvalidString(){
43.     emp.setPosition(" tester"); //extra space
44.     assertFalse(emp.getPosition().equals(" tester"));
45. }
46. }

As you can see, I have been using different variations of assert methods to check if the values that I have passed to setPosition() are saved to the position. Ideally, you should put as much assert cases as you can think of. Try not to put cases that are identical, as it is just a waste of the resources.

Now let's run the EmployeeTests class. Click on the icon. You should see the following screenshot:

Go to the Employee class, then to the setPosition(String) function (on line 30), and comment out the if statement (on lines numbers 31 and 33). Your setPosition(String) function should look like the following:

public void setPosition (String _position) {
//if (Arrays.asList(validPositions).contains(_position)){
    position = _position;
//}
}

Save your changes, go to the EmployeeTests class, and run it again.

After running EmployeeTests you should see the following output:

Create a Person class, the same way as we have created the Employee class in the first recipe, and put it in the how.to.eclipse package.

Your Person class will hold only one variable—name. It will also have one getter and one setter function.

Your Person class should look like the following code:

1.  package how.to.eclipse;
2.
3.  public class Person {
4.
5.      private String name; // private variable holding person's name
6.
7.  /**
8.  * This method sets name 
9.  */
10. public void setName (String _name) {
11.     if (_name != null && _name.isEmpty() == false){
12.     name = _name;
13.     }
14. }
15.
16. /**
17. * @return name
18. */
19. public String getName () {
20.     return name;
21. }
22. }

Create a JUnit test case called PersonTests in the how.to.eclipse.tests package the same way as we did in the previous recipe.

Test your name variable of the Person class for the following:

Right-click on the src directory and select New | Other… | JUnit | JUnit Test Suite. See the following screenshot:

Click on Next>.

In the next tab you will see that two of your tests are already checked, and the name is also provided as AllTests (make sure that the package is set to how.to.eclipse.tests). Eclipse is a very intuitive environment, and as I have already mentioned, some routine tasks are done by Eclipse automatically, thus saving us a lot of time.

Click on the Finish button. As a result, you should see the AllTests class created, and it should look like the following:

1.  package how.to.eclipse.tests;
2.
3.  import org.junit.runner.RunWith;
4.  import org.junit.runners.Suite;
5.  import org.junit.runners.Suite.SuiteClasses;
6.
7.  @RunWith(Suite.class)
8.  @SuiteClasses({ EmployeeTests.class, PersonTests.class })
9.  public class AllTests {
10.
11. }

As you can see, we have the @SuiteClasses annotation containing a list of the classes included in the JUnit Test Suite. If you want to add some more classes, just put them into the list separated by a comma.

Run the AllTests class.