Archive for the ‘Software Architecture’ Category


Goals of Test Driven Development

Why should you adopt Test Driven Development?  The answer is actually more complex than many people think.

Of course we all want to have fully tested code to ensure that the code operates as expected.  We also want to ensure that any new features do not break existing functionality (regressions), but what other reasons are there?



Introducing JTestConnect


A couple of months ago I finished the first version of JTestConnect. It is a tool for supporting development teams with their unit test strategies.

You can annotate your interfaces/classes with annotations describing how the object should be tested. The tool then sits in the build process and can interrupt a build if test classes/methods are missing.

Ideally, this would be added to a Continuous Integration build system to enforce test coverage of important classes.

A more detailed description of what it does can be found on the project home page.


Using EasyMock to Create Stub Objects

There are two competing philosophies with regard to unit testing strategies; state based testing and behavior based testing. In state based testing we configure a starting state, execute a test method, and then examine the resultant state/returned result. In behavior driven testing we ensure that our test object collaborates with its dependencies in an expected way.



How Anaemic Domain Models Cause Bad Software

Using an anaemic domain model is often considered an anti-pattern.  The reason for this is that it encourages coders to duplicate code needlessly.  This is going to be a fairly short (and fairly trivial) post explaining one of the mechanisms by which this occurs (with an example).  The mechanism can be avoided with careful planning and strict coding discipline but it is quite a lot easier to apply good encapsulation.  The difficulty with avoiding the pit falls of an anaemic domain increases exponentially as more team members work on the project.
None of this will be new for anybody with a moderate understanding of OOP, but it is interesting to see how a small number of fairly innocent steps can lead to a real mess.