If you have been happily using Easymock for the past years, this blog post is for you. Because you need to upgrade to Mockito, the new kid on the block in the mocking universe. Why bother about what mocking framework you’re using to create your unittests? Because it will improve you tests, make them more expressive, and help you write better code. Read on if you want to know more. Read the rest of this entry »
Posts Tagged ‘Testing’
Easier mocking with Mockito
August 13th, 2009 by Rob van Maris(http://blog.jteam.nl/2009/08/13/easier-mocking-with-mockito/)
Automated functional testing with WebDriver
August 5th, 2009 by Roberto van der Linden(http://blog.jteam.nl/2009/08/05/automated-functional-testing-with-webdriver/)
There is nothing nicer than having a functional test suite that checks if your application is still working as it should. It is even nicer to run these tests and see what is happening, while the tests are being executed. Two of the tools that give you this opportunity are Selenium RC and WebDriver.
In the project that I’m working on I use WebDriver to create functional tests. In this post I will try to give you an impression of why we switched from using Selenium RC to WebDriver and how we used WebDriver to test a Content Management System (CMS) and helped us making understandable tests.
Performance testing a Flex BlazeDS application
July 14th, 2009 by Rob de Boer(http://blog.jteam.nl/2009/07/14/performance-testing-a-flex-blazeds-application/)
In the past few years I’ve seen an increasing interest in Flex applications at our customers. I have to say that I’m not surprised about this trend. Not only do Flex applications generally look great, but they also provide a big boost to user experience. As a developer and architect I am also quite pleased with the programming model and extensive widget library. Sure, Adobe can still improve on a lot of things, but so far I have always worked with pleasure on Flex applications.
Read the rest of this entry »
Testing with factories
July 10th, 2009 by Tom van Zummeren(http://blog.jteam.nl/2009/07/10/testing-with-factories/)
On July 1st, Jelmer added a very useful blog post about testing the database layer in which he suggested to use “insert statement” and “fixture” classes to provide a good way to insert test data into your database. I am also using that technique as I’m writing unit tests for the database layer. I have to say this really makes unit tests less work to write, more focussed and therefore more fun to write!
Although this technique solves the challenges we have in database layer tests, we might encounter similar challenges when writing unit tests for other layers (such as the service or frontend layer). This is because such tests often also require “test data” you need to create. Only this time the test data is not in the form of database rows, but in the form of Java objects. Such objects need to be instantiated in a valid state and often depend on other objects. I find this quite similar to inserting rows into database tables having not null columns and/or foreign key constraints.
Read the rest of this entry »
Testing the database layer
July 1st, 2009 by Jelmer Kuperus(http://blog.jteam.nl/2009/07/01/testing-the-database-layer/)
The database is an integral part of many applications and writing queries is often hard. For that reason I have always written integration tests for the data access objects or DAO’s that I use to access the database. The way I write my DAO tests has changed a lot over the years and in this post I’d like to document the ways in which it has changed and why.
EasyMock: capturing arguments passed to mock objects
September 22nd, 2008 by Rommert de Bruijn(http://blog.jteam.nl/2008/09/22/easymock-capturing-arguments-passed-to-mock-objects/)
EasyMock2 is a library that provides an easy way to create on-the-fly mock objects based on interfaces. It can be used in combination with JUnit to create simple and powerful unit tests. Here’s an overview of the basic EasyMock flow, followed by a brief example that demonstrates a new feature in EasyMock 2.4: capturing arguments passed to MockObjects.
EasyMock2 basics
Lets assume we’re testing a ManagerImpl object that requires a Dao object to do some work. The manager passes a String object to the dao, and receives an Integer in return. Since we only want to test the Manager object in isolation, it seems a good idea to mock the Dao object.
The Dao interface:
interface Dao {
Integer poseQuestion(String question);
}
The Manager interface + implementation:
interface Manager {
String poseQuestion(String question);
}
With implementation:
class ManagerImpl1 implements Manager {
Dao dao;
public String poseQuestion(String question) {
return dao.poseQuestion(question).toString();
}
// Dao setter etc
}
EasyMock basically does the following:
- Create a mock object from the Dao interface:
Dao mockDao = createMock(Dao.class);
- Inject the mock object where an actual implementation would have been used:
manager.setDao(mockDao);
- “Record” all expected method calls to this mock object, and define appropriate responses. So-called argument matchers are used to put constraints on the expected arguments passed to the Dao
expect(mockDao.poseQuestion( // the expected call and( // merges the 2 matchers below isA(String.class)), // value is a String? eq("What's the meaning of life?")) // value equals given String? .andReturn(new Integer(42)) // define the return value for this method call .once(); // This call is expected only once. - When all expected calls are recorded, put the mock object in “replay” mode
replay(mockDao);
- In replay mode, call the manager which in turn will call the mock object in its natural habitat
String theCorrectAnswer = manager.poseQuestion("What's the meaning of life?"); - Afterwards: verify if all expected calls to the mock object were actually made.
verify(mockDao)
Capturing arguments
Now let’s say the manager in the above example does not pass the String argument directly to the Dao. Instead, it uses a Wrapper object as an argument for the dao method calls. The Wrapper object contains the String argument from the manager call, and some additional arguments only used in the Dao (e.g. for logging).
interface Dao2 {
Integer poseQuestion(Wrapper questionWrapper);
}
class ManagerImpl2 implements Manager {
Dao2 dao;
public String poseQuestion(String question) {
Wrapper wrapper = new Wrapper();
wrapper.setQuestion(question);
wrapper.setDate(new Date());
// wrapper.setMore(...)
return dao.poseQuestion(wrapper).toString();
}
// Dao2 setter etc
}
To fully test this ManagerImpl2 class, we’d like to know exactly what arguments are stored in the Wrapper object when it’s passed to the dao. The isA(Wrapper.class) matcher is of no help: checking the type of the Wrapper argument is not enough in this case. We want to check the specific values inside it.
EasyMock 2.4 offers a new feature to do just that. An additional capture(Capture c) matcher was added. This Matcher does not actually match anything, but stores the object passed to the mock object in a Capture object. Calling the getValue() on this Capture object later on will return the original argument. In this example, capturing the Wrapper object as it’s passed to the dao allows us to check whether it still contains the String that was used as an argument in the manager call.
A complete unit test for ManagerImpl2 would contain a method that looks something like this:
@Test
public void testPoseQuestion() {
ManagerImpl2 manager = new ManagerImpl2();
Dao2 mockDao = createMock(Dao2.class);
manager.setDao(mockDao);
Capture capturedArgument = new Capture();
expect(mockDao.poseQuestion(
and(
// capture the argument for later use
capture(capturedArgument),
// check if it is a Wrapper, as expected
isA(Wrapper.class)))
.andReturn(new Integer(42))
.once();
replay(mockDao);
// mockDao is used during manager call,
// the actual wrapper object is captured
manager.poseQuestion("What's the meaning of life?");
verify(mockDao);
// Check the captured argument: does it contain the original
// question, or was it modified by the manager somehow?
assertEquals("What's the meaning of life?",
((Wrapper) capturedArgument.getValue()).getQuestion());
}
The capture matcher allows for easy argument checking, without the necessity to implement additional mock arguments with custom equals/hashCode methods.
See the EasyMock2.4 documentation for more examples, and more useful tricks.