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?

1. Documenting code behavior by providing examples of usage: Developers can look at a unit test in order to better understand what the code is supposed to do.  A good test might also test exotic inputs (null values and invalid parameters) to ensure that they are handled correctly.  Such tests also demonstrate to readers of tests exactly what the code expects for input.  This is especially helpful when working in a team practicing “Collective Code Ownership” and in the highly likely case that a different developer will one day work on the code after the original author has moved on.

2. Ensure code testability: Writing unit tests for existing code can be a very frustrating experience, especially if code is too tightly coupled with other classes or a test harness cannot easily be constructed.  The cost can easily outweight the benefit in such cases and often it is simply too expensive to write tests for more than small pieces of untested code.  If this happens then you might have to just accept that your code isn’t ever going to have decent test coverage.  If tests are written before they are implemented then the implementation will implicitly be “testable”.  When new features are added to the class, it will be trivial to add a new unit test for the new logic.

3. Testable code is also well designed code: The reason why testable code is testable is because it has a clean separation of concerns and is usually well encapsulated.  This is means that your testable code is also well designed code.  Yes… writing tests will actually improve your code design.

4. Trying out new code first helps make its API better: How many times have you written a class that you’ve been proud of only to find out that when you actually start using it you find yourself wishing that the interface had been ever so slightly different.  Often some subtle (and unforseen) reason surfaces once you start actually trying to use your code that means that you have to change the methods on that class.  By writing a test first you are creating a client for your code.  This gives you the opportunity to look at how the design of the class from a unique perspective.  Perhaps the method calls could be made more readable with some small change, or perhaps some of the parameters are superfluous.  By trying out your class before it even exists, you can write your implementation code with the knowledge that it will be easy to use by client code.

5. Refactoring becomes a breeze: Actually, you shouldn’t really refactor code unless it has a unit test ensuring its correct operation.  The unit test should be run frequently between refactoring steps to ensure that your changes do not in fact modify the class behavior.  If programmers can refactor with a safety net then they are much more likely to actually do it, meaning better code for everyone.

Notice that 3 of the benefits only apply if the test is written before the implementation (i.e. using Test Driven Development).  By writing tests afterwards you are doing at least the same amount of work but missing out on some key benefits.

Writing unit tests does not always make sense however:

Contrary to popular belief, writing unit tests does have a cost associated with it which may be greater than the benefit.  More often than not, unit tests are seen as a holy grail which should always be applied.  Simply writing tests does not automatically mean that your project will be fault free and it certainly doesn’t automatically mean that your team will be more effective.  Instead, it should to be looked at like an monetary investment.  You will be incurring a real cost with the hope of recouping some benefit.  It may be that you lose out if you are not careful, but equally you can reap huge benefits if you do it right.  You should consider whether or not the benefit outweighs the cost on a case by case basis.  The factors for consideration should be:

1. How many developers will work on this project during its life? Better code APIs and documentation through tests means that the need for unit tests increases with the number of developers working on the project.

2. What is the skill level of your developers? Writing a good unit test is not easy.  Having poorly written tests which test the implementation too rigidly, or that are non repeatable, or slow, or test only trivial logic may incur a great deal of maintenance overhead.  It might be worth investing in some training before blindly jumping on the TDD bandwagon.  Developers should know what makes a good unit test and what makes a bad one.

2. Where is the project in its lifetime? If a project is nearing the end of its life and you are sure that it won’t be developed further then writing tests might not make sense.  You are making an investment with the hope that you can reap a benefit in the future.  If there is no future for the project, then the effort could be better invested in other ways.  A project just starting out however can benefit greatly over its lifetime with little initial investment.

On a final note:

Generally, bad test practices breed more bad test practices and good test practices breed more good test practices.  A team that is not performing well with regard to unit testing will find it only gets harder and increasingly more expensive to start.  A well performing team will find that writing tests and refactoring becomes a breeze and will continues to do so.  If you want to make a really good job of it make sure that you get it right, right from the project kick off.

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?

You can of course define a global property somewhere and update it whenever the application name changes. A nicer solution however would be to have the servlet context set the property automatically at startup.

To achieve this you will need to define a ServletContextListener:

public class ContextRootListener implements ServletContextListener {

	@Override
	public void contextDestroyed(final ServletContextEvent event) {
	   // Do nothing
	}

	@Override
	public void contextInitialized(ServletContextEvent event) {
	   ServletContextInfo
              .setContextPath(event.getServletContext().getContextPath());
	}

}

Note: ServletContextInfo is my property container class. It contains static getters and setters in this example.

Then you’ll need to register it as a listener in your web.xml.

	<listener>
		<listener-class>
                       com.snail.web.ContextRootListener
                </listener-class>
	</listener>

After this is complete you can get the context root at anytime using the static ServletContextInfo.getContextPath() method.

POWDER proves that graphics really isn’t everything when it comes to games.  POWDER is a Roguelike game, which means that you kill monsters, gain levels, zap things with magical wands and generally get involved in all sorts of fantasy RPG shenanigans.  Classic Roguelikes of the likes of Nethack and Angband are purely ASCII based and (in my opinion) aren’t very accessible.  With POWDER the entire game can be played using the mouse, and the keyboard shortcuts can be picked up bit by bit once you’ve got into the game.

It has been designed with hand held consoles in mind, but can be downloaded and played on Windows and Linux alike from the author’s web page.

Behind a somewhat simplistic facade is a deep and complex game that will take you a very long time to master. Each time you play (and die) there is something new to be learned for the next time you delve into the dungeon.  The first time I played the game indicated that I was hungry.  I decided to eat a slug that I had just killed, only to be poisoned and die.  Naturally I avoided doing that in subsequent attempts.  There is even a tutorial to help you get started.

A wiki exists for impatient players who don’t want to find everything out for themselves.  I still haven’t figured out how to stop myself from starving to death once I get a bit deeper into the dungeon.

Update: Two interesting things I also think are worth mentioning.

Roguelikes aren’t purely fantasy based.  There are a great deal of science fiction based games, include a version of Doom implemented in ASCII.

Also, there is a yearly competition where programmers try to create a fully playable Roguelike in just 7 days.  The short time encourages programmers to try out and explore new ideas and end up with a finished product at the end.

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.

function isHTML5CanvasSupported() {
    return (typeof HTMLCanvasElement != 'undefined');
}

function isHTML5VideoSupported() {
    return (typeof HTMLVideoElement != 'undefined');
}

function isHTMLClientSideDBSupported() {
    return (window.openDatabase);
}

Have fun!

Near to Tikal in Northern Guatemala

When applying a strictly state driven unit test strategy we can experience an explosion in the number of stub objects in our test code. Our System Under Test (SUT) requires dependencies that operate in a predetermined way (so that we can successfully predict the outcome/resultant state). This is more complex to set up, but gives the advantage that we are less fragile in the face of changes to our SUT implementation.

Our behavior driven brethren are laughing fanatically at our test strategy ideology, whilst enjoying the benefits of EasyMock.
Mock objects are different to stub objects in that they record behavior rather than returning canned values. EasyMock is a nice tool that allows us to record operations and expectations on classes, replay those expectations against the actual operations performed and then verify that what really occurred matches that which was expected. Easy mock makes building a test very easy, although if the implementation changes the order in which methods are called, or the parameters used, or indeed which methods are executed at all, our test may break. This can lead to tests which are potentially fragile, and difficult to maintain.

The ideal of testing purely for state rather than behavior is somewhat of a pipe dream however in that we still have to supply stub objects/dependencies so that our SUT can execute. We still need to make some assumptions about our implementation to know that it will fetch data from a particular stub, or that it will use a particular getter. It is more general however and a stub could be made general enough to support multiple test methods or multiple tests. Getting this right is what makes a unit test, a good unit test.

Wouldn’t it be nice if we could use a tool like EasyMock to generate our stubs, rather than program them over and over again, or maintaining a large set of shared stubs? EasyMock is, thankfully, powerful enough to allow us to create stubs.

In the example we will create a stub for the following interface:

public interface IMyService {

    public Integer getData();

    public String convert(Object object);

}

The code that could be added to a unit test class to provide a stub for this interface with canned responses is as follows:

/**
  * Sets up all mock objects.
  */
@Before
protected void prepareStubs() {
    this.myStubObject = EasyMock.createMock(IMyService.class);
    prepareStubResponses();
}

/**
 * Generates the canned responses.
 */
private void prepareStubResponses() {
    EasyMock.expect(this.myStubObject.getData()).andReturn(new Integer(5)).anyTimes();
    EasyMock.expect(this.myStubObject.convert(EasyMock.anyObject())).andReturn("ABC").anyTimes();
    EasyMock.checkOrder(this.myStubObject, false);
    EasyMock.replay(this.myStubObject);
}

First we create the stub object, then we configure an expected call to “getData” and we return the canned response “new Integer(5)”. The important thing that we have done here is to relax the expected number of calls to “.anyTimes()”. This means that we are not interested in the number of executions. We also switch off the expected ordering of calls. Setting “false” in check order means that EasyMock doesn’t care anymore if “getData” is called first, or if “convert” comes first. Finally we replay the stub in order to “start” it.

There is a shorter way to implement this however using “andStubReturn(..)”. The code would then look as follows:

private void prepareStubResponses() {
    EasyMock.expect(this.myStubObject.getData()).andStubReturn(new Integer(5));
    EasyMock.expect(this.myStubObject.convert(EasyMock.anyObject())).andStubReturn("ABC");
    EasyMock.replay(this.myStubObject);
}

Using “andStubReturn(..)” instead of “andReturn(..)” means that the call can be made any number of times. Order is no longer checked, so we can eliminate the “.anyTimes()” suffix and the order disabling command.

To further improve our stub code, we can use “EasyMock.createNiceMock(..)” instead of “EasyMock.createMock(..)”. A “nice” mock always returns a value regardless of whether behavior has been specified or not, rather than causing an error.

We will never verify the stub, so we are not checking that the methods are called, we don’t care about the order or the number of executions. We simply state that if this method is called, this response is to be returned. The stub can still be made general enough to be shared between tests and it carries no more assumptions than creating an explicit stub does, but eliminates the burden of having lots of extra classes.

Random Numbers