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?

Feedback Loop: A Must-Have for Every Action We Perform

Feedback is an essential notion in usability. This is the notion which struck me the most as I read the book « Design of Everyday Things » by Donald Norman and of which I am now the most attentive to in my every-day life. This article explores the way we can apply the feedback concept in other field than usability.

But first *how can we define what Feedback is? *

Feedback is data or results which are given in return for a completed action. me


Every action should have a reaction Arnie Lund

Feedback is also a central concept in system theory, especially cybernetic system theory, every action performed by a system on another one needs a feedback to measure its effect and so adjust its action to the reaction it perceives. You can replace « system » in the previous sentence with « human ». Also the feedback can be asynchronous with a response delay that can vary in time.

Examples Of Feedbacks In The Physical World

Donald Norman, in his book, uses as an example telephone keys which produce a sound when they are correctly pressed (a different sound to every key too). This allows the user to know that his action has been taken into account.

On my part, I remember for example having rented a car of a recent model a while ago and during the ignition not hearing the engine (‘feedback’) and spending 30 seconds just looking for a feedback to my action of ignition, actually the dashboard lights were on but unfortunately they were flooded in sunlight. Until I finally put it into gear and the car started going in reverse – the engine was on and the car had been operational the entire time!

Another example is the knobs which control the volume on my old Dell had a horrible feedback: a bar would appear on the screen but gave no indication of what the real level of volume was. Now on my Mac, as well as the appearance of a visual bar, the volume buttons emit a beep of the volume which has been modified by my action – a feedback I personally find much more useful!

In short, every action must have a feedback worthy of the name, especially in software!

Agile Practices Are Built With Feedback Loops

I find that the Feedback notion is a fundamental one and can be applied to our organizations. It is also a good way to explain the Agile practices as they are part of a feedback loop with just a different time laps which depends on the action (I stick to the number 3 to emphasize the unit change for each practice, a kind of Rule of Three ! :-) ). Hence:

  • Pair programming: feedback within 3 seconds
  • Unit tests: Feedback within 3 minutes
  • Refactoring and continuous integration: feedback within 3 hours
  • Standup meeting and planning: feedback within one to 3 days
  • Iteration: feedback within 3 weeks

The Lean Startup movement and the Minimum Viable Product (MVP) notion also try to integrate a feedback loop with startup’s clients during the product or service building process.

This feedback can sometimes be quantitative and very rational like with practice of A/B testing which consists of providing two different version of the same website/application and collect metrics about the different behaviors from users according to each version.

The faster the return, the better, which is why real-time BI systems are popular. Because, like in real life, feedback makes it possible to adapt the action in a continuous manner according to the returns.

In short, every activity can be questioned according to the feedback it returns. And how about you, what are your feedback loops for your activities?