Nothing Too Serious

Web programmers know that they shouldn’t go writing JSPs with the Context Path hard coded in them.

If you do the following:

   <a href="/MyApp/path/to/controller/home.htm> Home </a>

You’ll notice that as soon as you decide to deploy your web application using a different name than “MyApp” then none of your links will work anymore.
To avoid this you need to get the context path from the HttpRequest object as follows:

   <a href="<%=request.getContextPath() %>/path/to/controller/home.htm>
     Home
   </a>

or by using a JSTL tag:

    <a href="<c:url value="/path/to/controller/home.htm"/>"> Home </a>

What happens when you are rendering HTML in your Java code and you don’t have access to a HttpRequest object for whatever reason?

Continue reading

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.

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.

Continue reading

I’ve been playing around with Domain Driven Design (DDD) and trying to write a small web application without implementing an anemic domain model.  I have found that it is more difficult than it ought to be and I want to share some of my experiences.

An anaemic domain is something that happens in an enterprise application when your domain objects don’t really contain any real logic.  Instead the logic nearly all resides in a secondary “service” component.  This is an example of badly encapsulated code and will lead to messy, difficult to maintain applications.

Continue reading