A Blog about Business, Enterprise Architecture and Software Design by the Founders of ZenModeler

Unit Test In Real Life

Test Driven Development is an essential practice of the Agile approach. It allows an immediate feedback on the development activity and most of all it participates in the design activity by allowing it to emerge little by little according to the advancement of the system tests (great presentation on Emergent Design (PDF) by Neal Ford). I really like to try to transpose software concepts into the real world and unit tests are a part of this attempt, this article is an essay about what units tests looks like in real life.

A test is composed of the following elements:

  • A component to be tested situated in a very specific state (sometimes called the fixture)
  • The action performed on that component (sometimes called the System Under Test)
  • The assertion that can be done on that component after this action

These three components of a test can be summarized with the famous triptych Given/When/Then from BDD. Now let’s go back to the real world, the tests that we’re going to be able to carry out will sometimes concern real persons (“people”) with whom we interact. So, if I apply the BDD triptych in real life, the given fixture is the person, when that person does something, then I assert the result. Here are a few examples of unit tests IRL (In Real Life):

An anecdote is linked with the hard rock band Van Halen about their tour demands which have been deemed unrealistic and capricious (Thanks to @espritriche for telling me about that anecdote !:-)). In the contract they made their contractors sign during their tour included a particular clause which demanded that a bowl filled with M&Ms must be placed at their disposal in their lodge, BUT the bowl could not contain ANY brown M&Ms. David Lee Roth tell us the story in his biography:

I came backstage. I found some brown M&M’s, I went into full Shakespearean « What is this before me? » . . . you know, with the skull in one hand . . .and promptly trashed the dressing room. Dumped the buffet, kicked a hole in the door, twelve thousand dollars’ worth of fun. The staging sank through their floor. They didn’t bother to look at the weight requirements or anything, and this sank through their new flooring and did eighty thousand dollars’ worth of damage to the arena floor. The whole thing had to be replaced. It came out in the press that I discovered brown M&M’s and did eighty-five thousand dollars’ worth of damage to the backstage area.

The presence of even one brown M&M's in the bowl was enough to cancel the contract in its entirety with no compensation for the contractor. Actually this is the perfect example of an IRL Unit Test because this has nothing to do with rock-star diva-ism since the reason for this clause is to allow the group to check that the contractor has carefully read all of the clauses of the contract. If the M&M clause wasn’t respected, the group had every reason to assume that the other more important clauses hadn’t been as well ! In the case of the presence of brown M&Ms, the stage was effectively incapable of supporting the weight of the equipment for the tour. The contractor hadn’t taken into account the exact weight of the equipment specified in the contract just as he hadn’t taken into account the infamous brown M&M clause.

Another example which is appropriate for our geek activities comes from a post by Derek Sivers.

If you’re looking to hire a service provider on Odesk or Elance you can include in the specifications of the job a clause asking for a short and easy action like this one: “To separate you from the spammers, please write I AM A REAL GEEK as the first line of your bid. We will delete all bids that do not start with this phrase, since most bidders never read the requirements. Thank you for being one who does.” You’ll get many offers, but if they don’t have your magic phrase at the top (“I AM REAL” or whatever), delete them. This is very hard to do, since you’ll feel thrilled that so many people are offering to help, saying things like, “We have looked at your project and would be glad to complete it immediately,” but trust me and delete those. If they didn’t read something marked as VERY IMPORTANT already, you don’t want to work with them.

Another one is the post from Jeff Atwood last week about « How to hire a programmer? »

I know it sounds crazy, but some people who call themselves programmers can barely program. To this day, I still get regular pings from people who tell me they had candidates fail the most basic programming test imaginable. That’s why extremely simple programming tests are step one of any sane interview process. These tests should happen online, and the goal is not to prove that the candidate is some kind of coding genius, but that they know what the heck programming is. Yes, it’s sad and kind of depressing that this is even necessary, but if you don’t perform this sanity check, trust me – you’ll be sorry.

Some services that do online code screening (I am sure there are more, but these are the ones I know about) are Interview Zen and codility.

(UPDATE 04/06/12 : I’ve stumbled upon that very good one hiring filter from Chris Stucchio in Hacker News):

The sanity check he proposes first is a simple « Hello world » to be written by the applicants, it’s a kind of unit test as it involves very little action on your own to be performed and can then very easily filter the wheat from the chaff afterwards.

To summarize, in your offer you can include a task which is easy to do for the service provider and easy for you to check. If it isn’t done, you can be sure the rest of your demands might be treated the same way.

But what are the other kind of assertions we can perform? the easiest being the assertions linked to time (being on time for an appointment, etc.). Odesk even includes a tool which allows them to take a regular screenshot of the contractor’s screen and then allowing you to check the contractor’s activity. For cyclic assertions like in agile projects, unit tests can then be regularly executed so as to insure a constant feedback and to not deviate from a goal. The practice of Standup meetings is for me a part of a regular feedback loop at the core of the team allowing team members to get feedbacks from their peer’s actions as everyone tells the others: “what I’ve done, what I’m doing, what is blocking me, what I’ve learned, how I feel”. I can’t think of an assertion (other than a binary one) about a person’s location, maybe you’ve got examples to give in comments?

The assertions made above concern external people but now can we make our own assertions on ourselves? The “quantified self tools” are part of these tools which allow us to have a feedback about our own activities : on my part I use “Run Keeper” for jogging, “Rescue Time” for my professional activities and “Sleep cycle” for my sleep.

And what about you, which tests do you do in real life?