Tags
agile, Continuous Delivery, Modularity, OOD, OOP, Software Craftsmanship, TDD, Test First, Unit Test
“Every revolution was first a thought in one man’s mind”
Ralph Waldo Emerson
A number of years ago I remember going to youth group with a friend of mine and playing this super-fun game called “Sardines”. The rules were basically: one person 
hides – then everyone searches and whoever finds the hider hides alongside them until everyone (except for one person) is hiding at which time the lonely soul that is still searching is declared the “loser”.
The reason I bring it up – is because this game reminds me a lot of something that is happening in the software world. A subtle revolution has been taking place – and almost everyone who finds out about it quietly joins in and hides alongside the rest of the group that is “in-the-know”.
Now not everyone so quietly sits down and joins the can of sardines – every once in a while, like the kid who just couldn’t bear his friends becoming the loser, someone speaks out and gives away the group’s hiding place.
One of the most recent and best articulations of this revolution is from Steve Freeman and Nat Pryce – their expression is so compelling that even if they just stopped with the title of their 2010 book they would have pushed our industry forward several big steps – “Growing Object-Oriented Software, Guided by Tests“.
Ok – let’s stop and absorb that.
There has been a lot of talk about Test Driven Development and Writing Tests First – and these are both good and important ideas. But they are more like things we feel like we need to bolt on to our technique as an optional upgrade. In reality – the entirety of our engineering technique needs to be based on using testing as a guide.
But Why?
Guiding your development with testing buys two major advantages – confidence as you make changes to code as well as enhanced modularity and conceptual integrity.
Modularity is a very important ingredient in having an effective agile process. Monolithic software breaks agile processes as it leads to difficult planning and engineers stepping on each others’ toes during development – having an effective agile process through enhanced modularity means faster (and more fun) delivery.
Modularity is also very important in releasing as frequently as possible (see Continuous Delivery – by Humble and Farley). An optimized delivery pipeline means getting software in front of users quickly and frequently – which means more *actually useful* feedback. This means more value to customers faster.
Ok! How do I join in the fun?
There are several major things that you can do:
1) Read! Start with the Freeman and Pryce book listed above – then hit Google. There is a lot of material available about the specifics of writing unit tests.
2) Find a Mentor! Unit Testing is an art – if you can find a mentor who knows about it and practices it regularly you will put yourself on the fast track.
3) Don’t disengage your brain! Always question every practice – to make sure that you are understanding it for yourself. When it comes to “doing unit tests right” – do not take the word of your mentor, a website, or even your own mother – think for yourself.
4) Keep following this blog! We will follow up shortly with a very in-the-code and specific expose into the writing of a unit test.
But how do I sell this?
We programmers don’t like to be the Traveling Salesman – because we know it’s a difficult problem to start with (NP-Hard actually). But the pragmatists among us realize that our 
colleagues, our boss and probably others get grumpy if they think we are spending time on things that aren’t bringing value to the organization.
Fortunately that is not the case in our situation – code that is guided by good testing practices is easier to read as well as easier and less risky to change. Selling this to people who haven’t been directly involved in this practice should be as easy as a short (though non-trivial) proof of concept effort.
The one thing to remember if you do need to convince others within your organization – as with any tool or technique there will be a learning curve for every individual that hasn’t had experience with it before. This should not be viewed as a problem with a tool – but just a natural part of growing the skill level of the team. Every organization expects its members to be continually enhancing their own abilities while balancing the demands of accomplishing short-term objectives.
Next Steps
All you have to do is get started. Be creative of course – if you’re new to testing and you don’t want to try it at work until you are more comfortable with it maybe practice a little after-hours or on your breaks first.
Making this shift – to guiding your development with testing – will make your software even more incredible.
