ch.harmen.blog

It’s official: Sis, you’re nuts and we love your for that!

Harmen Weber — Tue, 20 Apr 2010 19:17:20 +0000

Some long time ago, I posted about my sister who became the first hobo in our family. Last year she sold all her belongings, bought a bike and took off for a biking trip. She hitch-hiked up north through Germany, France, Denmark, Netherlands, England, Scotland and all the way back again.

After more than 4’500 kilometers she finally had enough and came home. About 2 weeks at home she started looking for a job. We already thought it can’t be a typical one. It must be something … crazy, somehow?

Today, I came to know she found what she was looking for. I hope I get it right: She will work on a farm full of Scottish cows in a small town called Coglio.

What we thought? Ehrm, moooooh?

Sis, maybe you could point out little bit more clearly where that farm is in Coglio. And you could recharge your prepaid cell phone … do cell phones even have reception in Coglio?! I’m just saying…

Oh look! I think I just found the Scottish cows of Coglio! Mooooooh!

View Larger Map

Amendment to those that have the Google Earth Plugin installed: Coglio looks even nicer in 3D.

Coglio and Cows through the goggles of the Google Earth Plugin

Filed under: friends

Francine’s Tour

Harmen Weber — Mon, 27 Jul 2009 18:14:00 +0000

A few days ago, my sister has left everything behind, sat on her bike and head north. Congratulations, sister, you are the first hobo in our family ;-)

No, honestly, we are all jealous back here. As much as we’d love to follow your example, we know we are all too soft to stand such a trip.

Keep sending your trip reports, sis! We keep track on the map.

View Larger Map
Posted in friends

Moving a Subversion Repository

Harmen Weber — Thu, 04 Sep 2008 20:22:00 +0000

Follow the steps:

Execute the command below to get a dump of all committed changes on the specified repository:
```
svnadmin dump /path/to/repository > repository-name.dump
```
Compress the dump using:
```
gzip repository-name.dump
```
Move the dump to your target location
Decompress the dump
```
gunzip repository-name.dump.gz
```
In case you have not yet created a repository at your target location:
```
svnadmin create target-repository
```

Apply the dumped commits to your target repository:

svnadmin load target-repository < repository-name.dump

Done.

Of Snakes and Tigers

Harmen Weber — Sun, 20 Apr 2008 09:34:00 +0000

That’s Grisgris. He might look a bit chubby and dumpy … and dozily … and maybe even a bit lazy.

But whenever he’s not dreaming of fresh tuna slices, grilled rabbit chops or tandoori mutton, he releases his inner tiger. Birds, mice, bugs and spiders cover our trophy wall. His newest acquisition and his (or should I say ‘our’) pride and joy is this little snake … I didn’t even know we had snakes here.

So, does anyone have an idea what snake that is?

What is your pet’s latest acquisition on your trophy wall?

About the Scope of Unit Tests

Harmen Weber — Sun, 23 Mar 2008 23:13:00 +0000

Most unit tests I have seen and created so far had the wrong test scope. They depended on having the involved units/components to be integrated already and further they depended on the units/component to be implemented correctly. They were in fact more like integration tests rather than unit tests. Let me summarize my today’s thoughts about what the right scope of unit tests should be. Let me point out my current understanding of the purpose and therefore the scope of unit tests.

On Wikipedia I could find the following regarding unit tests:

In computer programming, unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, etc., while in object-oriented programming, the smallest unit is a method, which may belong to a base/super class, abstract class or derived/child class.

And although I’ve heard so many agreeing on this definition and claiming to have understood and applied it, I also saw tons of unit tests in my daily work that proof the opposite.

Example

Let’s look at a very simple scenario to discuss the correct scope of unit tests: Let’s assume we have a very simple partner management module that is split into two layers:

an integration service layer that provides integration services through data access objects.
In our particular case, the integration service layer holds a PartnerDao and a RoleDao to persist and retrieve Partner and Role entities.
a domain service layer that provides domain services for our partner management domain.
In our particular case, the domain service layer consists of a single PartnerManagement service providing methods to work on/with the partner management domain and it’s domain entities Partner and Role.

The business in the partner management domain service layer is rather simple, most methods provided by the PartnerManagement service just validate the input data and then delegate to the corresponding DAO of the integration service layer.

Let’s take a look at the sequence diagram of the exemplary createPartner(…) method provided by the PartnerManagement service.

The important thing when unit testing the application is (and that’s what I feel is often misunderstood and not followed properly) that each unit must be tested independently. To test a unit means to ensure that the unit is working properly, disregarding any other involved units and their business logic.

The unit tests for unit A

must test all business logic of unit A,
to ensure the unit A has been realized correctly!
must be independent of any other involved units
to ensure we test the business of unit A only
so that we have a clear test scope, it must be absolutely clear what gets tested where
i.e. it must not test any business logic of any other involved units,
to ensure that other units can change their business logic back and forth
but our unit tests for unit A remain accurate and successful
and it must not depend on the the other units to work properly
to ensure that the unit tests of unit A are still successful even when other units break

The unit test for the PartnerManagement.createPartner(…) method could look as follows:

source: PartnerManagementIntegrationTest.java

private ApplicationContext applicationContext = null;
private PartnerManagement partnerManagement = null;

@Before public void setUp() throws Exception {

applicationContext =

new ClassPathXmlApplicationContext(

"ch/harmen/partnermanagement/bus/application-context.xml");

partnerManagement =

(PartnerManagement) applicationContext.getBean(

"ch.harmen.partnermanagement.bus.PartnerManagement");

}

/**
 * Test the createPartner service:
 *     asserts that a valid partner gets created successfully
 */
@Test
public void testCreateAndFindPartner_02() {

// Create test partner

// Since we have already integrated the real implementation
// of CreatePartnerValidator,

we have to create valid input data
// otherwise the creation will fail (which is not intended in this case).

// This implies that this unit tests knows the business
// of the CreatePartnerValidator, i.e. the unit

must know what a
// valid partner is.

// In case the validation business logic changes,
// it might be that this unit test must be changed also,

// since the data passed here is not valid anymore after the change.
String firstname = "Harmen";
String name = "Weber";
String email = "harmen.weber@gmail.com";

// Assert that test partner does not yet exist
Partner returnedPartner = partnerManagement.findPartnerByEmail(email);
assertNull(returnedPartner);

// Create the test partner
// Asserts that after creation of the test partner, // the test partner has got an ID
// and asserts that the attributes are correct.
returnedPartner = partnerManagement.createPartner(firstname, name, email);
assertNotNull(returnedPartner);
assertNotNull(returnedPartner.getId());
assertEquals(firstname, returnedPartner.getFirstname());
assertEquals(name, returnedPartner.getName());
assertEquals(email, returnedPartner.getEmail());

// assert that the test partner was created successfully
returnedPartner = partnerManagement.findPartnerByEmail(email);
assertNotNull(returnedPartner);
assertNotNull(returnedPartner.getId());
assertEquals(firstname, returnedPartner.getFirstname());
assertEquals(name, returnedPartner.getName());
assertEquals(email, returnedPartner.getEmail());

}

What I want to point out here is that the ‘unit test’ above is not really testing the unit itself. It is doing a lot more than that.
The ‘unit test’

requires the application context configuration to be correct … it actually tests it to some extent
requires the PartnerValidationHelper
requires the PartnerValidationHelper to be realized correctly
requires the PartnerDao
expects the PartnerDao to be realized correctly

To make it short: this ‘unit test’ is far away from testing the unit PartnerManagement.createPartner(…) itself.

It depends on having the involved units integrated,
i.e. it will break once the integration contains errors
It even depends on the involved units to be realized correctly,
i.e. it will break once the other units break
And even worse, it claims to know the business logic of the involved units,
i.e. it will break once the business logic of the other unit changes

Identifying Unit Test’s Real Scope

Let’s go back to the sequence diagram (see above) and analyse what the business logic and therefore the test scope of the unit PartnerManagement.createPartner(…) really is:

The unit does nothing more than

first, calling the unit PartnerValidationHelper.validatePartner(…)

passing the correct partner information, equal to what was passed in the first place

second, calling the unit PartnerDao.createPartner(…)

in case the validation was successful
passing the correct partner information, equal to what was passed in the first place

thirdly, to return whatever the PartnerDao.createPartner(…) has returned

still in case the validation was successful
without making any further modifications/validations/whatever

that’s it and that’s all that must be tested, no more and no less.

How can that be achieved? An answer to that is the jMock library. With jMock, mock objects can be created. During the unit test, these mock objects are created and injected to the unit that is about to get unit tested. Like that the unit test does not depend on a correctly integrated application and further it does not depend on other involved units to be correctly realized.
Further, jMock provides the possibility to define expectations about how these mock objects are expected to be used by the unit and how the mock objects must behave when used. Like that, the behavior of involved units can be simulated, e.g. an involved validation unit can be simulated to return validation errors or to not return validation errors.

The following code snippet shows a unit test that does not depend on having all involved units integrated properly. Further it does not depend on the involved units to be realized correctly and won’t break on changes of the business logic of the involved units:

source: PartnerManagementTest.java

/**
 * Test the createPartner service:
 *     assumes validation successful
 * and  asserts that the call gets correctly delegated to the PartnerDao
 * and   asserts that the partner returned by the PartnerDao gets returned unchanged.
 */
@Test
public void testCreatePartner_01() {

// create a jMock context
Mockery context = new Mockery();
// create mock objects
final PartnerDao partnerDaoMock = context.mock(PartnerDao.class);

final CreatePartnerValidator createPartnerValidator =

context.mock(CreatePartnerValidator.class);

// inject mock objects into partnerManagement service
partnerManagement.setPartnerDao(partnerDaoMock);
partnerManagement.setCreatePartnerValidator(createPartnerValidator);

// define test data
final String firstname = "Harmen";
final String name = "Weber";
final String email = "harmen.weber@gmail.com";

// define what we expect to get instantiated // and passed to the createPartnerValidator and partnerDao
final Partner partnerToBePassed = new PartnerImpl();
partnerToBePassed.setEmail(email);
partnerToBePassed.setFirstname(firstname);
partnerToBePassed.setName(name);

// define the return value that should be returned by the createPartnerValidator
// we do not add any validation errors to the validation result, //so the validation will be successful
ValidationResults validationResults = new ValidationResults();

// define the return value that should be returned by the mockPartnerDao
final PartnerImpl mockedPartner = new PartnerImpl();
mockedPartner.setId(new Long(72));
mockedPartner.setEmail(email);
mockedPartner.setFirstname(firstname);
mockedPartner.setName(name);

// define sequence of delegated calls to createPartnerValidator and partnerDao
final Sequence createPartnerSequence = context.sequence("createPartnerSequence");

// define expectations regarding calls to createPartnerValidator and partnerDao
context.checking(new Expectations() {{

// validate service to be called once
// with a partner containing the correct attributes

one(createPartnerValidator).validate(partnerToBePassed);
inSequence(createPartnerSequence);

// createPartner service to be called
// with a partner containing the correct attributes

one(partnerDaoMock).createPartner(partnerToBePassed);
inSequence(createPartnerSequence);
// partnerDaoMock to return the mockedPartner object
will(returnValue(mockedPartner));

}});

// call service
Partner returnedPartner = partnerManagement.createPartner(firstname, name, email);
// assert expectations to be fulfilled
context.assertIsSatisfied();
// assert returnedPartner, in this trivial case, // we expect the partnerManagement to not have changed any
// values on the mockedPartner returned by the partnerDaoMock.
// In another scenario/service, maybe the partnerManagement // must do some calculations and change/set
// some attributes on the mockedPartner returned by the partnerDaoMock
assertEquals(mockedPartner.getId(), returnedPartner.getId());
assertEquals(mockedPartner, returnedPartner);

}

Summary

Be aware about the correct scope of your unit tests: A unit is the smallest testable part of an application that can be tested independently. Your unit tests must not depend a proper integration of involved units and they must not depend on the correct realization of involved units. Use mock objects (e.g. jMock) to unit test your units independently. The benefit of having independent unit tests (i.e. unit tests with the correct scope: only the unit itself) is to have more stable unit tests with the same coverage and the guarantee that in case of changes to the business logic of a unit only unit tests of the changed unit will have to be updated.