Unit testing the Eclipse way – Part 1
In Part 1 of this series, Michael Nyika discusses Unit Testing using Eclipse.
Does your legacy code demand a matching test suite of classes to run against its source code base? For such purposes, jMock qualifies as a great testing framework. However, not all cases may suit the occasion, especially when you must construct objects in a manner that jMock doesn’t expect. To avoid the hassle of producing suites of custom mock objects to support the unit tests in an application, you can tailor RMock to work with jMock seamlessly to achieve a positive result.
Mock objects mimic the behavior of classes written with the sole purpose of guiding code execution so that it falls within those areas under test. In time, the number of mock objects can grow with the number of application classes. Frameworks such as jMock, RMock, and even EasyMock help eliminate the need for a physical and separately existing set of mock objects.
One major disadvantage of the EasyMock framework is that you can’t mock concrete classes — only interfaces. In this article, I show how you can use the jMock framework to mock concrete classes and interfaces, as well as how to test certain obscure cases with RMock.
Configure jMock and RMock in the Eclipse IDE
Begin by launching the Eclipse integrated development environment (IDE). Next, create a basic Java™ project into which you’ll import the JUnit, jMock, and RMock Java Archive (JAR) libraries. Name the Java project TestingExample. Within the Java Perspective, choose Project > Properties, then click the Libraries tab, as shown below.
Figure 1. Editing properties for TestingExample project in Eclipse
Use the Add JARs button when the JAR files are in the Java classpath (that is, the Java Runtime Environment (JRE) you have configured within Eclipse). The Add Variable button applies to a specific directory in which resources (including JARs) on a file system (local or remote) reside and can be generally referenced. Use the Add Library button when you must reference those specific resources that are a default in Eclipse or configured for a specific Eclipse workspace environment. Click Add Class Folder to add a resource from one of the existing project folders already configured as part of the project.
For this example, click Add External JARs and browse to the jMock and RMock JARs you downloaded. Add them to the project. Click OK when the properties window shown in Figure 2 appears.
Figure 2. jMock and RMock JARs added to TestingExample Project
The TestExample source code
For the TestExample Project, you’ll be working with the source code from four classes:
- ServiceClass.java
- Collaborator.java
- ICollaborator.java
- ServiceClassTest.java
The class under test will be ServiceClass, which contains a single method: runService(). The service method takes an object named a Collaborator, which implements a simple interface, ICollaborator. A single method is implemented in the concrete Collaborator class: executeJob(). Collaborator is the class you must mock appropriately.
The fourth class is the test class: ServiceClassTest. (The nature of the implementations has been simplified as much as possible.) Listing 1 shows the code for this fourth class.
Listing 1. Service class sample code
public class ServiceClass {
public ServiceClass(){
//no-args constructor
}
public boolean runService(ICollaborator collaborator){
if("success".equals(collaborator.executeJob())){
return true;
}
else
{
return false;
}
}
}
|
In the ServiceClass class, the if…else code block is a simple logical crossroad that helps show why the test would fail or pass if one path — and not another — is taken, according to test expectations. The source code for the Collaborator class is shown below.
Listing 2. Collaborator class sample code
public class Collaborator implements ICollaborator{
public Collaborator(){
//no-args constructor
}
public String executeJob(){
return "success";
}
}
|
The Collaborator class is also simple, with a no-arguments constructor and a simple String returned from the method executeJob(). The code below shows the code for the ICollaborator class.
public interface ICollaborator {
public abstract String executeJob();
}
|
The interface ICollaborator has a single method that must be implemented in the Collaborator class.
With the above code in place, let’s move on to examining how you can run your test of the ServiceClass class successfully in different scenarios.
In Part 2 of this series, we will continue by showing Scenarios where jMock can can be used to simulate interface calls.
StumbleIt! 
Comments
No comments yet.
Leave a comment