The Importance of Stubs

Wow, I haven't posted in a while. I'm still crunching away at the game but a few things have popped up at home that have kept me from spending too much time. Leaky basements and a new puppies tend to do that I guess.

Nothing new to report with the game, still just hammering away at the game's user stories. I did switch over from Continuum to Cruisecontrol for my integrated environment. I've been trying out git-svn with some success and liking it for the most part.

So to make this post a bit more interesting I decided to rant about something that I've seen in a couple of teams I've worked with both as a developer and as a coach. The issue is that of having dependencies on other teams for artifacts that are critical to my team's product. This is especially problematic with larger organizations pushing for an "enterprise" solution - which typically translates into multiple development teams working separately for months trying to configure an off-the-shelf, over-priced product and then throwing everything together in an integration nightmare and regression testing for a period that might out last the actual development time.

Being responsible for a product that you don't fully control all the moving pieces can be frustrating and at times paralyzing. But I've found a solution that's produced some good results: create a stub of everything that you depend on but don't control.

For example, if your team is building a web client that consumes services for all of your back-end work, stub out each of the services that you rely on. Define an interface that your team and the team building the service can agree upon and build a basic implementation.

If you're relying on a web service that provides search capabilities, get the WSDL and generate a client and service. Put just enough implementation into the service to make it functional. Have it return one of ten result sets based on ten different query strings - something simple but functional as far as inputs and outputs.

Once you have the stub in place, you can write your automated UATs (User Automated Tests) around your application using the stub and ensure that your application is processing the results correctly. Once your UATs are in place and you have your continuous integration environment, you can swap in their actual services and just kick off the build to verify the integration. This should make it fairly painless!

Now obviously the interfaces can change as the project continues but just make sure that when the changes occur, all dependent teams get an updated version of the interface. Then it's as simple as regenerating the stub service and client code and making a few adjustments here or there. Then run the UATs again to ensure that you have integrated the changes correctly so that the behavior of your application is still what the user expects.

I'm convinced that this practice alone will save large development departments millions of dollars of teams wasting their time trying to throw everything together at the last minute. And it will probably save developers the stress of the integration nightmare.

End rant.