So understanding how a unit test is traceable back to a technical design on an agile team is really a key differentiation between an approach that more closely resembles cowboy coding and an approach which is relatively holistic.  No scrum master, project manager, or even architect would advocate full designs in an agile environment – instead we opt for lighter weight approaches to technical design that provide a blueprint to the code.  For many teams, this is a CRC card – a simply way of documenting the various dimensions of an object-oriented unit.

What is a CRC, and how does it relate back to tests?

Class

The core unit of code that we will refer to is the class, but this can be really any aggregation – a function library even.  This represents a loose collection of related functionality that leverages common resources, represents a concept of actions or identity, or extends existing functionality.

Responsibilities

The responsibilities of the class form it’s raison d’etre. Commonly, we can analogize responsibilities with methods, but they may be more coarse grained – and our refactoring may indeed refine the level of detail with which we understand the functional responsibilities of the class.

Collaborators

From an interestingness perspective, particularly in the context of unit testing and mocking (or stubbing), collaborators really take the cake.  When we talk about dependency injection as the core pattern of test-driven development with mocks, collaborators are indeed what we are injecting into our class to power it.

I always ask my green developers to think about these things before starting any sort of development.  Once their CRC is done and we agree on the approach, I ask them to build the programming interface, stub the implementation, and then start writing tests.  A common example I like to use when I get that befuddled look is the idea of a car.  A car has a lot of complex stuff going on that if I needed to test dependent functions of the car against, I wouldn’t want to have to concoct all of the function they provide.  For instance, the engine is a complex piece of machinery – but if I solely want to to test how my transmission reacts to engine behavior – it’s the transmission class I want to ultimately test, and it’s reactions to different engine behavior.

Let’s bring it up a level and talk about a Car as the core class.  We want our car to be able to do two things – to have two responsibilities: accelerate and stop.

public interface Car {
   int accelerate(int additionalVelocity);
 
   void setTireGrip(int gripFactor);
 
   int stop(int overDistance) throws CannotStopException;
}
 
public interface Motorable {
   int injectGasoline(int mlOfFuel);
}
 
public interface Stoppable {
   int applyBrakes() throws PadException, RotorException, WetRoadException;
}

So we’ve defined 3 interfaces. Let’s say that I’m really interested in a case where I test how the car reacts to different stopping conditions. Now, I’m demonstrating this in Java, so I’ll use syntax similar to Mockito – but the rules are the same: I’m interested in testing the requirements of the car observing the expected behavior of the brakes in those conditions. When the grip is set low, we expect the braking system to respond negatively and lock up.

We’ll also assume for now that I’ve stubbed out a skeletal implementation of the Car interface (meaning that everything throws a NotImplementedException for the time being).

@Test
public void testWetRoadConditionsWithLowFriction() {
 
   // arrange
   Stoppable s = mock(Stoppable.class);
   Motorable m = mock(Motorable.class);
 
   Car c = new CarImpl();
   c.setStopAbility(s);
   c.setMotor(m);
   c.setGripFactor(3);
 
   when(s.applyBrakes()).thenThrow(new WetRoadException());
 
   try {
      // act and assert - no real assertion, we're expecting an exception
      c.stop(100);
      fail("Should have seen a CannotStopException - there's not a lot of grip for road when road conditions are wet");
   } catch(CannotStopException e) {
      // do nothing, we're a success!
   }
}

As you can see, we’re not actually testing the brakes – we’re testing that under the given conditions that when the Stoppable interface throws an exception that prevents our car from stopping successfully that we are throw our own CannotStopException in response. The stoppable interface is a collaborator; we are not interested in this case in unit testing it, we are interested in asuming a known behavior from it, and testing how the stop() ability of the Car implementation reacts to the WetRoadException that we have stubbed.

The alternative in the past would have been to actually create the implementation of Stoppable. But having to unit test both items makes it difficult to isolate implementation issues.

So ultimately young developers, your unit tests need to test a single responsibility and not the responsibility of your collaborators. You may eventually test how the two implementations interact – that is an integration test. Ultimately though, there is more value in testing each individual unit and ensuring that the code is built to the spec of your lightweight design. Then you can isolate integration issues and write tests that specifically address finding integration problems.

I haven’t been architecting Java solutions for a living in nearly a year now, and last I checked the state of the world was more or less:

• EJB had assimilated Hibernate and other ORM solutions as something now called JPA, which was neccesary and useful to standardize;
• EJB had also taken elements of Spring to invert the once ubiquitous locator pattern and adopt dependency injection as the standard for satisfying collaborator relationships.  Of course, the Sun solution aimed to solve specific problems in EJB, and had less interest in solving the more general need for standardization around DI-based application frameworks;
• JSF was crashing and burning in the web tier, with Gavin King once again trying to pick up the pieces and simplifying the entire stack through Web Beans.

So to distill it down – middleware in Java was actually a pleasurable place to work, and the web tier was still a torture chamber.

Note: I’m leaving Velocity, Struts, Spring, and Tapestry out of the mix here.  That’s not to say that there isn’t value in some of these frameworks.  Tapestry was architecturally sound but hinders rapid development.  Struts and Spring both require siginificant configuration, and Velocity is…like Smarty for PHP.  All of them did so many things differently that it would be difficult to standardize around any one of them.  Additionally, the only one that could arguably be standardized within the exiting JEE stack is Spring – which attempts to solve many of the problems of front and middle-tier integrations.

Per my post from the other day, I really feel that the age of the server-based Web UI framework is dead.  MVC will always be a necessity, but re-usable controls and architectures that try to solve all of the world’s problems with different delivery mechanisms be it HTML or JSON are at a dead end – it’s simply not scalable.  So my attention turned to an article by James Strachan about JSR-311 and how he feels it could be the standard to solve much of the worlds problems.  JSR-311 addresses the JAX-RS standard for delivery of RESTful services.  This has long been needed from Sun given the narrow nature of the JAX-WS spec, but James has the right idea.

…Having had a horrid time using Tapestry and Hibernate together on some projects in the past, I’m kinda over the whole concept of server side UI web frameworks personally (I’m putting my flame-proof suite on now). I kinda think if you want to do complex rich web UIs, use wizards or complex flows, just use GWT or JavaScript on the client (or Flex/Flash for video or crazy highly graphical widgets) and keep the server side fairly simple and very RESTful….

So, I’m not the only crazy one out there.  That’s comforting.  But is a standard that serves as the foundation for tools to deliver RESTful services the answer?  From an architecture perspective, I’ve always been of the mindset that RESTful services, particular with its HTTP metaphors is just a DAO pattern exposed as services.  This is a pretty fine grain for me, but as Seam in Java and LINQ in .Net are beginning to prove – the value of coarse grained business services as provided typically by Session Beans in EJB may be a bit overstated.  So, does it make sense to build web frameworks that are really geared towards SaaS, and allow frameworks like Spring or Velocity or, hell even simple XSLT – take the helm when more traditional request-response mechanisms are needed?

And even more so, a cursory review of the JAX-RS doesn’t really present any options for consuming the services produced by implementers.  That’s somewhat understandable given that the product is typically vanilla XML or JSON or Text or whatever.  When I wrote my own RESTful service implementation using Spring a few years back, I made sure that XSD was attached and available when the service was XML.  This made it easy to write JAXB clients if your consumer was another Java application.  Slowing down development by forcing homogeneous consumers to parse the response as DOM seems like a likely outcome of not having SOME way of addressing this issue.

Taken together, I’m on board with the idea that JSR-311 could be a good foundation for a web framework that treats the client as being smart, rather than the dumb terminal approach of the past.