In my 2-day TDD course a couple of the things we go into are value types and of contract tests. It occurred to me recently (while writing a new value type within Apache Isis) that I really should have a contract test for any value type. That would allow me to easily check that the value type’s equals() method was an equivalence relation (ie symmetric, transitive, reflexive) and that its hashCode() is consistent with equals().

What I came up with is the ValueTypeContractTestAbstract<T> class. This is how you would use it to test that java.lang.String#equals() meets the equivalence relation:

Read the rest of this entry →

I’ve been delivering my TDD course today, one topic of which is writing custom matchers in Hamcrest. One topic that came up was in asserting state within large object graphs, so it struck me that a nice general purpose matcher would be one that used an expression language to navigate the graph.

For example, given a customer that has an address, which has a city, which has a name, then it’d be nice to be able to say:

assertThat("London", navigableFrom(customer, "address.city.name"))

where navigableFrom() is the factory for the matcher.

So, without further ado, here’s a set of tests for such a matcher: Read the rest of this entry →

Taking a break from my series on putting a custom UI on Naked Objects, in a week or two I’ll be running my TDD training course. The client this time wants EasyMock instead of JMock (which is what I normally teach), so I’ve spent an hour trying to figure out how to get the automatic verification (that JMock’s own JUnit runner gives) along with easily using Hamcrest matchers in expectations. I also wanted a way to easily switch between mocking concrete classes or just interfaces.

Anyway, here’s what I’ve cooked up. Given an object to test:

package com.mycompany;
import com.mycompany.TeaMaker.MilkAmount;
import com.mycompany.TeaMaker.SugarAmount;

public class TeaDrinker {
	private TeaMaker teaMaker;
	public void setTeaMaker(TeaMaker teaMaker) {
		this.teaMaker = teaMaker;
	}

	public void drinkTea() {
		teaMaker.makeTea(SugarAmount.ONE_SPOON, MilkAmount.JUST_A_DASH);
	}
}

and a collaborator (that we want to mock out):
Read the rest of this entry →

I use JMock as my preferred mocking library. Most of the time the expectations I write are pretty simple, indicating that a mock should return this value, or should throw this exception. For example:

mockery.checking(new Expectations() {{
 allowing(mockConfiguration).getString(
     "nakedobjects.persistor.adapter-factory",
     PojoAdapterFactory.class.getName());
 will(returnValue(PojoAdapterFactory.class.getName()));
}});

However, I recently needed wrote a little API whereby Injectable components will inject themselves into any objects that declare itself to be aware of that component. For example, we have a SpecificationLoader:

Read the rest of this entry →