We all have it. It’s that piece of code in our project that everyone is afraid to change. It’s so confusing no one truly understands what is going on. We are all afraid that if we do change it, we’ll break it. You have just discovered my favorite reason for writing unit tests. But how do you write a unit test? What exactly is a unit test? How do I handle dependencies? And how is writing more code going to make my existing code better? This tutorial will show you how.
What is a unit test?
For the case of this tutorial, we’ll define a unit test as a test of a single isolated component in a repeatable way. Let’s go thru that one section at a time to get a clearer idea of what goes into a unit test.
“a test”. This means to verify something is correct. In order for us to have a valid unit test, we need to actually validate that after a start condition A, an end condition B exists. “…a single isolated component…”. This is what separates a unit test from other types of tests. In order for it to be a unit test, it must test something in isolation, aka without dependencies. The reason for this is that we are testing the component itself and not it’s interaction with other components (that is an integration test). Finally, although most definitions don’t include this piece, “…in a repeatable way” is a very important piece of the definition. It’s one thing to run a test that passes. It’s quite different to have something you can run in a repeatable manor at any point to see if changes you made effected how the component behaves. For example, if you choose to do some refactoring to improve performance, can you rerun your unit test to verify that you didn’t change the behavior of the component.
Setup
I will be using Eclipse 3.3 Europa to do this tutorial. To begin, create a new java project and call it JUnitTutorial. Right click on your new project and select New –> Folder. Name it lib and click Finish. Usually you don’t want to package your test code with your regular code, so let’s make an additional source directory, test. To do that, right click on your new project and select Properties. Select Java Build Path from the available options. In the Java Build Path window, click Add Folder. From the Add Folder dialog, select Create New Folder, name it test and click Finish. Next we need to add JUnit to our build path. Since it comes with Eclipse, all we need to do is to go to the Libraries tab, click the button Add Library, select JUnit and click Next. Select JUnit 4 and click Finish. Click ok to exit the Preferences window. We will also need to download and add the EasyMock jar files to our project. You can find the jars here. Once you download the zip file (we are using version 2.3 for this tutorial), extract the easymock.jar file and place it in the lib folder you created earlier. In Eclipse, right click on your project and select Properties. On the menu to the left, click Java Build Path and select the Libraries tab. Click the button Add Jar on the right. In the window that pops up, add the easymock.jar and click Ok. Click Ok to close the Properties window. You should now be ready to start your development.
The requirements
In test driven design, we develop the unit test before the functionality. We write a test that verifies that the class should do X after our call. We prove that the test fails, we then create the component to make the test pass. In this case, we are going to create a service with a method that authenticates a user. Below is a class diagram of the scenario.
The interfaces
We will start our coding by defining two interfaces, LoginService and UserDAO We will implement LoginService, however since in this tutorial UserDAO will be mocked, we won’t bother implementing it right now. For LoginService, we have a single method that takes a String userName and String password and returns a boolean (true if the user was found, false if it was not). The interface looks like this:
/**
* Provides authenticated related processing.
*/
public interface LoginService {
/**
* Handles a request to login. Passwords are stored as an MD5 Hash in
* this system. The login service creates a hash based on the paramters
* received and looks up the user. If a user with the same userName and
* password hash are found, true is returned, else false is returned.
*
* @parameter userName
* @parameter password
* @return boolean
*/
boolean login(String userName, String password);
}
The UserDAO interface will look very similar to the LoginService. It will have a single method that takes a userName and hash. The hash is an MD5 hashed version of the password, provided by the above service.
/**
* Provides database access for login related functions
*/
public interface UserDAO {
/**
* Loads a User object for the record that
* is returned with the same userName and password.
*
* @parameter userName
* @parameter password
* @return User
*/
User loadByUsernameAndPassword(String userName, String password);
}
The test case
Before we begin development, we will develop our test. Tests are structured by grouping methods that perform a test together in a test case. A test case is a class that extends junit.framework.TestCase. So in this case, we will begin by developing the test case for LoginService. To start, in your test directory, create a new class named LoginServiceTest and make it extend junit.framework.TestCase.
The lifecycle of a test execution consists of three main methods:
•public void setUp()
setUp is executed before each of the test. It is used to perform any setup required before the execution of your test. Your implementation will override the default empty implementation in TestCase.
•public void testSomething()
testSomething is the actual test method. You may have many of these within a single test case. Each one will be executed by your test runner and all errors will be reported at the end.
•public void tearDown()
tearDown is executed after each test method. It is used to perform any cleanup required after your tests.
So to begin flushing out our test case, we’ll start with the setUp method. In this method, we’ll instantiate an instance of the service to be tested. We’ll also create our first mock object, UserDAO. You can see the source of our test below.
import junit.framework.TestCase;
import static org.easymock.EasyMock.createStrictMock;
import static org.easymock.EasyMock.expect;
import static org.easymock.EasyMock.replay;
import static org.easymock.EasyMock.verify;
import static org.easymock.EasyMock.eq;
/**
* Test case for LoginService.
*/
public class LoginServiceTest extends TestCase{
private LoginServiceImpl service;
private UserDAO mockDao;
/**
* setUp overrides the default, empty implementation provided by
* JUnit’s TestCase. We will use it to instantiate our required
* objects so that we get a clean copy for each test.
*/
@Override
public void setUp() {
service = new LoginServiceImpl();
mockDao = createStrictMock(UserDAO.class);
service.setUserDAO(mockDao);
}
}
EasyMock works by implementing the proxy pattern. When you create a mock object, it creates a proxy object that takes the place of the real object. The proxy object gets it’s definition from the interface you pass when creating the mock. We will define what methods are called and their returns from within our test method itself.
When creating a mock object, there are two types, a mock and a strict mock. In either case, our test will tell the mock object what method calls to expect and what to return when they occur. A basic mock will not care about the order of the execution of the methods. A strict mock, on the other hand, is order specific. Your test will fail if the methods are executed out of order on a strict mock. In this example, we will be using a strict mock.
The next step is to create our actual test method (for reference, we will not be implementing a tearDown method for this test case, it won’t be needed in this example). In our test method, we want to test the following scenario:
Even with the very basic method we want to test above, there are still a number of different scenarios that require tests. We will start with the “rosy” scenario, passing in two values and getting a user object back. Below is the source of what will be our new test method.
…
/**
* This method will test the “rosy” scenario of passing a valid
* username and password and retrieveing the user. Once the user
* is returned to the service, the service will return true to
* the caller.
*/
public void testRosyScenario() {
User results = new User();
String userName = “testUserName”;
String password = “testPassword”;
String passwordHash =
“�Ӷ&I7���Ni=.”;
expect(mockDao.loadByUsernameAndPassword(eq(userName), eq(passwordHash)))
.andReturn(results);
replay(mockDao);
assertTrue(service.login(userName, password));
verify(mockDao);
}
…
So let’s go thru the code above. First, we create the expected result of our DAO call, results. In this case, our method will just check to see if an object was returned, so we don’t need to populate our user object with anything, we just need an empty instance. Next we declare the values we will be passing into our service call. The password hash may catch you off guard. It’s considered unsafe to store passwords as plain text so our service will generate an MD5 hash of the password and that value is the value that we will pass to our DAO.
The next line is a very important line in our test that alot happens, so let’s walk thru it step by step:
1.expect(mockDao.loadByUsernameAndPassword()
This is a call to the static method EasyMock.expect. It tells your mock object to expect the method loadByUsernameAndPassword to be called.
2.eq(userName), eq(passwordHash)
This code isn’t always needed. When EasyMock compares the values passed to the method call, it does and == comparison. Because we are going to create the MD5 hash within our method, an == check will fail, so we have to use one of EasyMock’s comparators instead. The eq comparator in this case will compare the contents of the string using it’s .equals method. If we were not doing the MD5 hash, this line would be expect(mockDao.loadByUsernameAndPassword(userName, password).andReturn(results);
3..andReturn(results);
This tells our mock object what to return after this method is called.
The final three lines are the ones that do the testing work. replay(mockDao); tells EasyMock “We’re done declaring our expectations. It’s now time to run what we told you”. assertTrue(service.login(userName, password)); does two things: executes the code to be tested and tests that the result is true. If it is false, the test will fail. Finally, verify(mockDao); tells EasyMock to validate that all of the expected method calls were executed and in the correct order.
So that’s it for the test. Now all we have to do is write the code to make it pass. You can find that below.
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
public class LoginServiceImpl implements LoginService {
private UserDAO userDao;
public void setUserDAO(UserDAO userDao) {
this.userDao = userDao;
}
@Override
public boolean login(String userName, String password) {
boolean valid = false;
try {
String passwordHash = null;
MessageDigest md5 = MessageDigest.getInstance(“MD5”);
md5.update(password.getBytes());
passwordHash = new String(md5.digest());
User results =
userDao.loadByUsernameAndPassword(userName, passwordHash);
if(results != null) {
valid = true;
}
} catch (NoSuchAlgorithmException ignore) {}
return valid;
}
}
Conclusion
So that is it. I hope this gives you a more in depth view into JUnit and EasyMock. Unit testing is something that once you get used to it, makes you code better, provides you with a safety net for future refactoring and protects you from being burned by API changes. I strongly encourage that you give it a try. Until next time.
Attachments
Eclipse Project: JUnitClass.zip
26 Responses
•Jonny Andersson responded:
This was quite a good little tutorial as an introduction on how to use EasyMock! I still think it is hard to understand how to use EasyMock, and a continuation of this tutorial would have been great. The API documentation (javadoc) is not very superfluous so it is quite hard to understand the power of it without good examples like this tutorial. It takes a little time to learn how to “think” when creating mock objects, at least for me. I guess it at least would have been easier if they had created some more explanations in the class documentation (in top of the generated javadoc) for the EasyMock class, and for example a little code example on typical use, but there is no documentation at all. An alternative would havebeen to link to some online tutorial.
•sraju responded:
I am a research scholar working on software test case optimizations.
•Stephen Turner responded:
Several errors in the code….
– LoginService interface needs to define setUserDAO method
– @Override in LoginServiceImpl generates a compile error
– closing paren missing at the end of this line:
expect(mockDao.loadByUsernameAndPassword(eq(userName), eq(password))
– The way the testRosyScenario method is written, the passwordHash variable is not used (you hand “password” to loadByUsernameAndPassword). I actually had problems saving the source code with the hard-coded string (encoding issues).
It would be great if the tutorial went on to explain how to actually run the test and how to interpret the results.
•Michael responded:
Stephen,
Thanks for the feedback! A couple quick notes:
– LoginService is correct. The test calls LoginServiceImpl. The implementation has the getters and setters for dependencies, not the interface.
– @Override annotation works fine for me.
– I have fixed the typos on the expect line (the missing paren and the second eq() should take passwordHash and not password).
– I apologize for the encoding issue. MD5 hashes aren’t HTML friendly. My intent was that readers would get the drift.
I have also added a zip file of my Eclipse project that I used to develop this tutorial. I hope this will help mitigate any confusion on the code itself.
Regarding the execution of the test, you can execute it two ways in Eclipse:
– The first (and my favorite) is to use the keyboard shortcut. Press Alt+Shift+X then T (for test).
– The second is to right click on LoginServiceTest and select Run As –> JUnit Test.
Finally, in order to interpret the results, there will be a bar that turns red if there is a failure during the tests or green if they all pass. If it turns red, there will be a window below that will tell you what the error was and on what line. Would it be helpful to go over test debugging in a future tutorial?
Keep the good feedback coming!
Michael
•Medyk responded:
As Stephen wrote before LoginService interface needs to define setUserDAO method or ‘service’ field needs to be LoginServiceImpl in LoginServiceTest class.
•Haider Shah responded:
The tutorial is very nice, detailed and easy to learn. By reading it only once i got a clear understanding about the Mock.
But a question arise in my mind that don’t you think it is lengthy as it requires a lot of code just to test a single login module. so what we gona do with the large system having say having more than 20 modules or more…
Kindly mail me at the given address and clear my confusion.
Regards,
Haider Shah
shah.d.gr8@gmail.comThis e-mail address is being protected from spam bots, you need JavaScript enabled to view it
http://www.dolcha.com
•Haider Shah responded:
public class LoginServiceImpl implements LoginService {
private UserDAO userDao;
public void setUserDAO(UserDAO userDao) {
this.userDao = userDao;
}
‘setUserDAO’ should be defined in the LoginService interface but it is absent.
you over ride login method, you must also define setUserDao in the interface, it is lgical error.
@Override
public boolean login(String userName, String password) {
boolean valid = false;
try {
•Michael responded:
Thank you everyone for your feedback!
Regarding the setUserDAO() being missing from the LoginService interface, that really isn’t the issue. The test should be (and now does) refer to LoginServiceImpl instead of LoginService. LoginService should not have the setUserDAO() method on it because that dependency is an implementation detail and not something that the consumer of the API should care about (IMHO).
I have updated the tutorial to make the correct reference. Thanks again and keep the feedback coming!
Michael
•Stephen Turner responded:
Hi Michael,
Thanks for the feedback – my mistake on the setUserDAO mthod. I had changed the code from your example.
The @Override error I got was in the LoginServiceImpl class – this is the message: “The method login(String, String) of type LoginServiceImpl must override a superclass method”.
Thanks,
Steve
•Shridhar responded:
Hi Michael,
We are heavy users of Easymock for unit testing most of our application. But i feel its just a pain to setup all the mocks for complex classes which has lot of dependencies on other components. It becomes harder to maintain all the mock setup when you change something in the code base and then you end up spending half a day fixing it. Sometimes i feel its not worth it.
I find regression and integration tests very useful.
•Michael responded:
Shridhar,
I’m glad to hear that you are using EasyMock. From the description of your experience, I wonder if either your code is too complex or you are testing too much with each test. Keep in mind that unit testing is intended to test very small, isolated pieces. Excessive mocking is a tell tale sign of either your code (say a method in the unit testing scenario) is too complex and should be refactored into smaller pieces that can be unit tested separately or that you are testing too much and that the piece you are testing isn’t isolated enough. Good luck!
Michael
•Teja Kantamneni responded:
Its a pretty nice roundup on easymock, here is my little one on partial mocking of objects using easymock.
http://tejakantamneni.blogspot.com/2008/09/partial-mocking-of-objects-using.html
•Gayathri responded:
The tutorial is very simple and good, I started using easy mock for my DAO mock objects. And to start with this gives a easy understanding.
•Benjamin Lambe responded:
as for the @override this is a 1.5 JVM Specific annotation that tells the compiler that you are overriding this method with your own implementation.
In your code you are not actually overriding the login() method, but implementing it… so this @Override should be removed…. the reason why it will show up for some people and not others is if you have your compiler warnings/errors set up to show this.
Good tutorial though, I am a regular user of junit and easy mock, though i have to use easy mock 1.3 😥 becuase of our code base.
some of our tests can get extremely complex and you find yourself having to create lots of mocks, but helper methods help here where you create a helper method which will create the mock you are after and handles all the other mock creation for the objects you do not care about below it… so instead of creating 20 mock objects for your test you simply call
doCreateMockForxxx();
and you have helper methods for your expectations based on creating this mock
doSetUpExpectationsForxxx();
especially in testing workflow tests this is necessary, no matter how much you try and isolate your methods under test… one of my test files is 10,000 lines long 😉 but manageable…
I agree there are not enough tutorials on easymock etc… someone should really write some more (hint hint)
Keep up the good work
•Anjil responded:
Hi Michael,
The tutorial is interesting and useful. I was able to test some of my projects using EasyMock. But it needs me to always have the interface for every class which i want to mock. Is there any other way i can mock the classes without an inteface?
•Michael responded:
Anjil,
Thanks for the feedback. Regarding mocking classes, EasyMock has an additional package for that specific ability. Use org.easmock.classextension.EasyMock for mocking classes and org.easymock.EasyMock for mocking interfaces. I hope this helps. If not, let me know and I can go into more detail.
Michael
•Iftach responded:
Hi Michael,
I have one problem with the example. It’s still a bit coupled for me.
I think that the way LoginServiceImpl is handling the hash should also be injected into the LoginServiceImpl using a different service such as HashService.
That way you could test your HashService in another test case, and when testing the LoginServiceImpl, mock the HashService.
That kind of thinking gets me to respond on what Shridhar wrote.
I disagree with Michael that your code is too complex. It might be, but not necessarily. sometimes you have a lot of services in your program, and when writing a flow class that uses those services, you want to use more than one service, which is ok if non of the sub-flows has a meaning.
As you said it could make your test code a bit hard to manage.
I have 2 suggestions for you:
1. Test the edge cases using mocks (for an example: UserDao throws an exception). Usually test cases that test edge cases are clean.
2. Integration testing is a good idea in order to solve the problem, as long as you don’t do the integration tests all at once and just give up on unit tests.
Write different test cases that just integrate with 1-2 real services at a time. The rest of the services will still be mocked. It will keep your test code much cleaner. and will get some of the effect of unit testing.
Iftach
•hema responded:
His site gives the clear picture for junits using easyMock
•Andrew Cllegg responded:
Thanks for the nice demonstration!
BTW to those people having problems with @Override — it’s a JDK 1.5 vs. 6.0 thing. In 1.5 you can’t @Override an interface method, just a superclass method. In 6.0 you can, and to not do so causes a compiler warning. (Even though the terminology ‘override’ is wrong…)
•chary responded:
the greatest simplifier is the one who explains hard problem in a simplest possible way and not because to solve hard problem…this is one of the example
•Binu N Kavumkal responded:
Hi Michael,
The tutorial is very useful and it explains nicely the life cycle of a EazyMock and JUnit.
I have a couple of queries regarding mocking HttpServletRequest, HttpServletResponse and FilterChain
I want unit test a Filter class using EasyMock and JUnit.
In the doFilter(), I inspect the request parameter and if parameter contains a specific string, I would not allow the user to proceed further. Otherwise, user request can proceed.
How to test the Scenario?
In side the doFilter method based on the checking I am setting a flag.
I flag is true, I do the chain.doFilter(..)
Otherwise, sendRedirect to home page using response object.
If you have any idea, please let me know
•sakthi responded:
Hi … your Article is very nice, detailed and easy to get a clear view on Mock.
But it is lengthy as it requires a lot of code just to test a single login module. so what we gona do with the large system having many modules?…. I got another Article related to this from macrotesting site there its is very clear and they had used simple ideas in Mock that is good as your. you can see that article in http://www.macrotesting.com sure it will be useful. Thank you for this post…
•gunner007 responded:
hi, this is very useful. however i, still have questions and confusion about EasyMock and JUNit.
What is the relation of these two? I mean, JUnit can also be partnered with JMock.
Please advise. Thank you.
•akki responded:
How can we use easymock to test the EJB classes.
can any of you please provide an example as how to test some ejbs when we do RMI calls thru JUNIT test cases.
•chunjianyin responded:
it’s very good!
•Harihar responded:
This article was very helpful for me. It would be great if this tutorial is extended (like explaining more about the EasyMock and JUnit with some more examples).
Add your own comment…
contraivietnam.tk 
Bình luận về bài viết này