AssertionFailed...

A nice article. Lot of information. I have a small...

2008-10-10T02:20:00.000-07:00

A nice article. Lot of information. I have a small problem, though. I plugged in EclEmma to Eclipse and it works fine for stand alone applications. How does it work for web applications?

To expand on the concept of the Mockery, a simple ...

2008-08-08T17:21:00.000-07:00

To expand on the concept of the Mockery, a simple example:
Foo foo = EasyMock.createMock(Foo.class);

Bar bar = EasyMock.createMock(Bar.class);

Oof oof = EasyMock.createMock(Oof.class);

EasyMock.expect(foo.generateBar())
.andReturn(bar);

EasyMock.expect(foo.oofed())
.andReturn(oof);

From these humble beginnings, you can grow an immense Mockery.

Another side effect of excessive mocks is a straight jacketed test, where the test is brittle and confusing to be much more than a regression lock. Which doesn't help, because the failures are invariably hard to debug and fix.

@akuhn: Thanks for the great reply. Example driven...

2008-07-20T09:59:00.000-07:00

@akuhn: Thanks for the great reply. Example driven testing seems like an interesting approach, especially if you prefer to do TDD or EDD. But still, as you mentioned, the House test being shown as white due to a failed dependency means you wouldn't know if House works or not. There might be additional failures which you wouldn't catch until you fix the problem in Kitchen. With mocks on the other hand, Kitchen test fails, we know kitchen has a problem, while the House which uses a mock, and thus probably wouldn't be having the bug allows the House test to pass. Just my thought on the subject.

Well, yes, sadly we are not yet at the level of line level assertion failures. Thought generally, I try not to have too much same class method dependencies. Usually those kind of methods are private as well. And technically, you could mock out public methods with EasyMock, I believe.

First of all, thanks for the answer on my blog and...

2008-07-13T06:44:00.000-07:00

First of all, thanks for the answer on my blog and addressing my comment in a full blog post here. Let my structure this comment in two parts. First I will present example-driven testing, an alternative to mock-based testing. An alternative which I personally find more pragmatic. Ads second, I will show why we are still not at the level of source-line assertion failures.

1)

Given your House with a Kitchen, you propose to use a mock kitchen to test the house. However, setting up a mock can be quite some work. And why do that work if somewhere else we already do all the work of creating a working kitchen? Yes, if only there would be a return value at the end of the kitchen tests we could use that instead of the mock.

This is exactly what we do in JExample (a JUnit extension): we avoid all the mocks, because our test methods can have return values and dependency injections. Let me give an example

@Test
public Kitchen testKitchen() {
Kitchen k = new Kitchen;
// ... assertions
return k;
}

@Test
@Depends("testKitchen")
public void testHouse(Kitchen k) {
House h = new House(k);
// ... assertions
return h;
}

When executing testKitchen, the framework caches the return value: an example kitchen! When executing testHouse this example is injected as invokation argument in the test call.

If however testKitchen fails, the framework reports testKitchen as red and testHouse as white (ie failed due to dependency. Thus pin-pointing us to kitchen as the source of the failure!

Example injection is also very handy when testing different states of the same instance under test. You just inject the example from one test method to the next, thus testing all different states.

2)

Still, whether using mocks or examples, we are still not level of source-line assertion failures. Why? Even if you know the MUT (method under test) there is no bijective, ie 1:1, relation between methods and test-methods.
Given the method under test delegates to four private methods (ie 1:n), where is the bug the test fails?
Given two methods under test delegate to the same private method (ie n:1), where is the bug if only one fails?
EzUnit by Friedrich Steimann addresses these issues by analysing both the static and runtime coverage of tests and comparing it to each other.

But alas, their tool has no example injection :)

SO you do have time....

2008-07-12T00:07:00.000-07:00

SO you do have time....

You wrote:
>"Pin point breakages and ca...

2008-07-11T21:56:00.000-07:00

You wrote:
>"Pin point breakages and causes of failures to the line level"

Caught my attention. Do you refer to "line of test code" or "line of app code"? If the latter, how do you achieve this? With common unit test, you get the failing line of test code not the failing line of app code. Or even worse, one buggy app line causes dozens or hundreds of test to fail. What is your experience to deal with this?

AssertionFailed...

A nice article. Lot of information. I have a small...

To expand on the concept of the Mockery, a simple ...

@akuhn: Thanks for the great reply. Example driven...

First of all, thanks for the answer on my blog and...

SO you do have time....

You wrote:>"Pin point breakages and ca...

You wrote:
>"Pin point breakages and ca...