Home arrow Tutorials arrow Unit testing with JUnit and EasyMock
Unit testing with JUnit and EasyMock PDF Print
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.

JUnit class diagram

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:

JUnit sequence diagram

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

65 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
    This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
    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 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).

  • Usman responded:

    I work in the finance industry and trying to implement EasyMock for unit testing.
    Nice example, concise and understandable

  • Maarten Smits responded:

    Thanks Michael, your tutorial saved me several hours and got me started quickly.

  • panji wisnu wirawan responded:

    nice tutorial! thanks Michael!

  • Greg Skudlarick responded:

    Great Tutorial Mike. Were adding EasyMock to our test suite. Will be much easier then creating out own Mock Objects. I'll be using the Mock Extensions so we can Mock Classes as well as interfaces. Just need to make sure it's in the Maven Repo

  • Amandeep responded:

    Very Nicely explained. Good Job !!

  • mini responded:

    Its good but too lengthy to beginners.

  • Bond responded:

    Your explanation of EasyMock was much better than what they have on their own web site. They should add your documentation to their page.

  • Dinesh responded:

    Truly, It‘s a nice Tutorial on Easy Mock. I’m going to start using Easy mock but I didn’t find good tutorials on their site. Hat’s off

  • Travis Low responded:

    A helpful addition would be an explanation of what you can expect to see in failure cases, and what it means. I built the project as directed and all my tests failed until I modified LoginServiceImpl.java to skip the MD5 hashing, and modified the call to expect() in LoginServiceTest.java accordingly. The problem is that the failure looks like this:

    java.lang.AssertionError:
    Unexpected method call loadByUsernameAndPassword("testUserName", "p@ssw0rd"):
    loadByUsernameAndPassword("testUserName", "5—@œÚ™O‹U3†ØE"): expected: 1, actual: 0
    ...

    The issue with "expected: 1, actual: 0" is that at that point, I wasn't certain I had put the project together correctly. So I didn't know whether there was some structural problem with my code, or if the test was "really" failing. At first I thought that the method wasn't being called, that is "I expected the method to be called 1 time, but it was called 0 times". The semantics became clear to me as soon as I resolved the MD5 mismatch problem.

    Thanks for your efforts in writing this tutorial.

  • Monish responded:

    Very Simple & nice explanation !

  • CallieEstrada responded:

    I had a question around calling mocking out local methods.

    If I have a scenario like :
    interface.method1()
    myLocalMethod();
    and myLocalMethod() - calls some external database connection which I want stubbed out - how would I do this?

    I can't do expect(this.myLocalMethod()).andReturns(something) obviously.

    How else would this be possible?

  • Andy responded:

    I don't get it. The title of this article is "Unit testing with JUnit and EasyMock". Yet you are implementing integrations tests, not unit tests. Your definition of a unit test is "it must test something in isolation, aka without dependencies" but LoginService has a dependency of UserDAO. Please explain.

  • Mesothelioma responded:

    I read the test case its looking little bit difficult there is no alternate to test in other way??

  • Michael Minella responded:

    Andy,

    The test above is a unit test because we remove the dependency on the UserDAO by mocking it. An integration test would be one that actually executes the UserDAO and tests the results of the interaction between the two. Does that make sense?

    Michael Minella

  • Michael Minella responded:

    CallieEstrada,

    What you describe is a common scenario. Although I don't have an example handy, take a look at EasyMock's partial mock functionality. This allows you to mock a single method call instead of the entire object. You can read more about it here:

    http://easymock.org/EasyMock2_5_2_ClassExtension_Documentation.html

    Michael Minella

  • Jason responded:

    A great little intro to EasyMock

    I felt I had to explain a few things for the doubters. There are generally two reasons why EasyMock becomes hard to use.

    1. Classes are failing the coupling/cohesion principle and need to be refactored
    2. You are writing framework type classes that need to use the reflection API.

    The second case is rare for general applications and the first, as I mentioned, the answer is simple, refactor your classes to be loosely coupled and strongly cohesive.

    Almost every single time I have found Unit tests with EasyMock to be problematic or dificult, it is because of the simple fact that coupling/cohesion has been violated.

  • vbk responded:

    Hi,
    I have an Issue regarding easymock.how to expect the list values for a method.
    It is giving error for the following test as
    java.lang.AssertionError:
    Unexpected method call SomeMethodA([Pos@b2002f,Pos@2a4983]):
    SomeMethodA([]): expected: 1, actual: 0



    my code is like this..
    Test Method:
    service = new B();
    public void testUpload() throws IOException
    {
    List AList = new ArrayList();
    EasyMock.expect(OneClass.SomeMethodA(AList)).andReturn(AList);
    equals(service.SomeMethodB(bytes));
    }

    public class B
    {
    public List SomeMethodB(byte[] byteArray)
    {
    List posList = new ArrayList();
    positionList.add(1);positionList.add(2);
    List outList = OneClass.SomeMethodA(posList);
    return outList;
    }

  • Gui responded:

    try
    {
    [...]
    } catch (NoSuchAlgorithmException ignore) { }

    This is fugly.

  • Sarabdeep responded:

    Great Article. Concise and breif. Article in actual EasyMock documentation does not make any sense for startup developers.

  • kishore responded:

    Nice Article and Helped alot.

  • Pankaj responded:

    The tutorial is nice. Having read other tutorials on the web, I have a feeling that there is nothing "easy" about EasyMock. I am new to this and only experience in a live project will tell if all the mocking is worth it. If classes are designed with loose coupling and high cohesion, why have mocks - they should be easily testable by themselves. If they aren't, then EasyMock (or any other mock) isn't going to easy anyways.

  • skumar responded:

    Nice Article and Helped alot.

  • Daniel responded:

    Another Easymock Tutorial with Maven and Cobertura

  • Daniel responded:

    Another http://www.java-tutorial.ch/so...k-tutorial

  • a friend responded:

    http://sravanmodugula.blogspot...ymock.html

    Has the exact same example - do you publish under more than one URL?

  • Prafulla responded:

    This is really a nice article which easily explains how Easy mocks work

  • WulfgarPro responded:

    Good tutorial - clear and concise.

  • DrPep responded:

    try
    {
    [...]
    } catch (NoSuchAlgorithmException ignore) { }

    This is fugly.

    +1

  • Affordable Online Schools responded:

    I appreciate you sharing this important info here with us, it was interesting and useful!

  • Shiny Srinivas responded:

    Good one for starters

  • sindhu responded:

    it's very good

  • anu responded:

    it's very good.now i understand the need of mock objects.thank you

  • Randy Ynchausti responded:

    This is an excellent tutorial, but it does not address the question as to whether EasyMock should be used on a project for unit-testing. Since EasyMock creates significant debt in a project for a development team, I feel the author should have addressed this question. There are several key areas that might have been mentioned when deciding whether to use EasyMock:

    1) With EasyMock, the team will write the code three times (1-production code, 2-unit-test code and 3-EasyMock mock objects) instead of two times.

    2) EasyMock couples production code to unit-test code tightly.

    3) EasyMock obscures how much quality unit-testing is achieving.

  • Bahata responded:

    A really good article. First time got the gist of it.

  • Saji responded:

    Thanks a lot. Just what I wanted. Short but concise...

  • Junit testing responded:

    very good tutorial. Easymock rocks!!

  • Replica Watches for Women responded:

    Significant timepiece aficionados who're able to definitely make investments within a high quality gold observe have to check out the distinguished line of Longines watches readily available.
    http://lanasjewelry.com/cli/index.html

  • replica watches sold in the usa responded:

    If you're thinking about acquiring more than 1 pretend watches , make your purchase at our website. We will give you a terrific discount for bulk orders.
    http://www.actoverco.com/bvlgari/

  • Rav responded:

    hi,
    We are using IBM ODM (operation decision manager) API for one of our projects. we are calling to get connection, session, and many decision center related api call in our implementation methods.

    eg. IlrSessionFactory, IlrSession, IlrSessionHelper , IlrRuleProject.

    i am able to mock these but not able to invoke and call methods (my requirement:) which internally needs decition center projects, decisiont table , rows etc,

    I would like to know if EascyMock can be applied on methods that internally calls multiple decision center api calls.

    like mocking the database, can this ODM decision center be mocked compeltey...

    please help if this support 3rd party products - for their internal api method calls.

    Need urgent help on this.
    thanks
    Rav

Add your own comment...


busy
 
< Prev

Tweets

    Twitter Button from twitbuttons.com