EasyMock Fundamentals Series — Part 3

Welcome to the third installment in my EasyMock Fundamentals series where I take you through the ins and outs of the open source Java library.

By |May 28th, 2013|General|0 Comments|

EasyMock Fundamentals Series — Part 2

Each way gives you a mock object with slightly different behaviors/restrictions. Consult the EasyMock API for specifics, but unless you have valid reason to not, the preferred method is createNiceMock().

By |May 21st, 2013|General|0 Comments|

EasyMock Fundamentals — Part 1

In my three-part EasyMock Fundamentals series, I will take you through the ins and outs of the open source Java library. EasyMock can be used in conjunction with a unit testing framework, such as JUnit or TestNG, to facilitate better unit testing without all the 2nd degree dependency issues. EasyMock provides the means (through the use of mock objects) to specify the response that will be returned when the code being tested makes calls to external methods. This will allow the result of the unit test to be isolated from variables outside of the scope of the unit test code.
An Introduction to EasyMock Fundamentals

Refer to the official EasyMock documentation for more detailed explanation of the tool (latest as of this writing EasyMock3.1 Docs) including download, setup, and a brief usage example.

Please note that, for the sake of simplicity, not all the details of the code examples have been included.
Stubs vs. Mocks
An alternative to using a mock object is to create a stub object; a lightweight implementation of the interface for the external methods, that just return the expected response. These two approaches are best illustrated with an example.

Let us say you want to write a unit test for an object Foo that does something cool, doSomethingCool(), and uses another object, Emailer, to send emails while doing something cool as follows:
package com.partnet.foo;
public class Foo {
  private Emailer emailer;
  public Foo(Emailer emailer) {
    this.emailer = emailer;
  }
  public void doSomethingCool() {
    // something worthy of being unit tested
    emailer.sendEmail(…);
  }
}
package com.partnet.foo;
public interface Emailer {
  boolean sendEmail(…) throw EmailerException;
}
If you’re trying to test the doSomethingCool() method, you don’t want to, shouldn’t have to, and thankfully don’t need to worry about what emailer.sendEmail() does (assuming the implementation of the call has no impact on the code you’re testing of […]

By |May 14th, 2013|General|0 Comments|
Google+