The BDD style is very pretty. Certainly business people can easily read and write it. Moreover, the BDD style provides a conceptual framework within which automated test specification and be efficiently composed. Better still, the BDD tools provide a powerful parsing mechanism that conveniently translates the natural GWT statements into function calls to be executed as tests.

The problem is that the BDD style is simply not appropriate for all, or even most kinds of tests. Why? Because it’s wordy. Consider:

Given a Juke box that shows 0 credits
When I deposit .25
Then the Juke Box shows 1 credit.

Given a Juke box that shows 0 credits.
When I deposit 1.00
Then the Juke Box shows 5 credits.

Given a Juke Box that shows 0 credits.
When I deposit 5.00
Then the Juke Box shows 30 credits.

How is this better than:

Jukebox Credit Table

Deposit	Credits
25	1
1.00	5
5.00	30

• Which of the two is the more elegant?
• Which of the two is easier to read?
• If you were looking for a specification error, in which of the two would you be more likely to find it?

I think the answers are rather obvious.

• There is value in brevity.
• There is elegance in sparseness.
• Elaborate wordy structures are not always the best approach.

OK, I can hear the complaints starting to bubble up already; so hold on. I’m not arguing against BDD. I really like the GWT style. And Yes, I realize that many of the BDD testing tools allow you to compress your tests into tables so that you can avoid the wordiness.

My issue is not with the tools. My issue is with the idea that BDD is the only true way, and that all tests should be expressed in GWT format forever and ever amen.

Is this a strawman? Unfortunately not. In my travels over the last several years, I have seen this attitude showing up over and over again. Someone will write a suite of complex tests using GWT style, without realizing that they could shorten it by a factor of 10 or so by recomposing it into a simple table.

Actually my issue is with the tools. Cucumber, for example, is written around Given, When, Then. If you use Cucumber, or JBehave, or any of the other BDD tools, you think in GWT and find it hard to even express something as simple as the table above.

Consider, for example, the following strange test. It measures how well the juke box selects random songs based upon their popularity. More popular songs should be played more often than less popular songs. You might specify it this way in GWT style.

Given a Juke box with 1 credit
When the user presses “You Decide”
Then the juke box will randomly choose a song based on its ranking.

Now this is a perfectly good statement of intent, and I’d certainly want it to turn green if I ran the test. However, if this turns green, what have we really learned? The test result does not really tell us whether or not the selection algorithm is accurate. The GWT statements above are really just hand-waving statements that loudly say Trust Me without necessarily verifying anything.

Now look at the following tables.

Repeat you decide 10000 times and count results

Average credits should ~=1.3

Song	Times played
Stairway to Heaven	880 < _ < 1120
In-a-godda-da-vida	1880 < _ < 2120
Viva La Vida	2880 < _ < 3120
Incense and Peppermint	880 < _ < 1120
Comfortably Numb	2880 < _ < 3120

Perhaps you don’t like the magic numbers. There are ways to deal with that, but they are beyond the scope of this blog. So let’s forget about the magic-ness of the numbers for the moment. When you run this test you see something like this:

Repeat you decide 10000 times and count results

Average credits should 1.295 ~=1.3

Song	Times played
Stairway to Heaven	880 < 998 < 1120
In-a-godda-da-vida	1880 < 2007 < 2120
Viva La Vida	2880 < 2950 < 3120
Incense and Peppermint	880 < 1019 < 1120
Comfortably Numb	2880 < 3026 < 3120

It’s hard to argue that the green-ness is hand-waving. Nothing here says: Trust Me. You can see that the selection algorithm is random, and is weighted properly.

Now I’m certain that we could construct a set of GWT statements that captures the above semantics perfectly; but why would we? The simple tables express the intent in a format that is simpler and more accessible than GWT.

Conclusion

As programmers we have already learned that we must be polyglots. If you want to write a rails system you’d better know ruby, haml, css, erb, xml, etc. If you want to write a J2EE system, you’d better know Java, JSP, HTML, XML, CSS, etc.

Testers also need to be polyglots. Writing in a single style such as GWT is not going to cut it. GWT has it’s place, but it’s not sufficient. Other testing languages are also useful. Therefore testing tools need to be polyglot tools.

Step 0: Problematic Dependency

Step 1: Capture dependency in a single class

Step 2: Raise the abstraction to a domain-level interface

Step 3: Introduce test doubles as needed

Step 0

Step 1

Step 2

Step 3

I’ve included three different sources for the video. One of them ought to work for you. The higest resolution video is the quicktime/screencast version; but some people can’t use it. So choose your poison.

Viddler

link

---

Vimeo

link

Writing Maintainable Automated Acceptance Tests from unclebob on Vimeo.

---

screencast.com

(QuickTime) link

---

In my typical consulting role, I am often playing the role of facilitator, but I also have set myself up as an observer at the same time. In the past, this has seemed to make sense given I was the only consultant in the room. This recent experience, however, has really changed how I think about those situations.

In the design of Innovation Games®, the facilitator will typically have a number (1/2 – 1/3) of the participants serve as observers. This has several advantages.

• The facilitator can focus on one thing (think single responsibility principle).
• Different observers, different filters (we all have filters all of the time), resulting in more perspectives captured, giving better overall information.
• Given enough observers, you can have individual observers focus on specific things.
• Since the observers are typically from the team (not the consulting company), it reinforces the notion of ownership. The facilitator does not own the results, nor does s/he produce the results.

Why so many observers? Innovation Games® are designed to get access to the things you don’t know you don’t know.

Jerry Weinberg has a simple model of leadership. The MOIJ model.

• M is for Motivation
• O is for Organization
• I is for Innovation
• J is for Jiggle

In any situation, take a read. Do you have too much Motivation or too little? Too much? People are frantic and running around like kids just after getting back from a successful night of trick-or-treating. Too little? Everybody is exhausted from yet another all nighter getting ready for a demo because too much focus was placed on adding stuff rather than adding stuff well.

The same idea applies to Organization and Innovation. It is possible to have to much or too little organization and too many or too few ideas.

What happens when none of those first three seem to fit? That’s the Jiggle. You introduce some random element to see if you can get access to something you don’t know you don’t know.

With many observers (e.g. 8-10 in a group of 20), you have the flexibility to have someone look at hand gestures, someone to look at eye contact, someone to listen to change in vocal pitch, etc. That is, you have “typical” observers listening for “important” information and “jiggiling” observers searching form something else. Since you don’t know what you don’t know, doing things with specific kinds of observations might jiggle out information that otherwise you would have missed. It may not, that’s part of the problem of trying to work in the space of you don’t know you don’t know.

In any case, to me this is now one of those “intuitive once you know it” things. In the past, I have worked within my self-perceived constraints of being a single person with 2 roles needing to be filled. Maybe on an intellectual level I understood the value of having observers separate from the facilitator but I did not really grok it.

Now I think I do.

Will I always separate those roles? I don’t believe in context-free best practices, so no. However, will I make this my default preference? I’ll certainly work on it.

More specifically, how am I going to use this new knowledge?

In 2 weeks, Michael Feathers and I are co-teaching an Agile/XP Immersion in Seattle. I’ve already planned to use a few of the Innovation Games® during the class. The big difference, however, is that I’m going to encourage a number of the students to play the role of an observer (listening, recording, saying nothing) to give the customer a chance to own what’s going on rather than being the recipient of a technique.

I’m sure it will take me some time to embody this new approach as my default rather than falling back on the (up until now) current way I’ve been doing things. I’m sure I’ll stumble along the way. But as long as I keep making new mistakes and not repeating the old ones over and over, I’ll be moving in a good direction.

The difference between a laborer and a professional is that a laborer takes orders from his boss, and a professional provides input to his superiors. Laborers are hired to take direction. Professionals are hired to ensure that the direction chosen makes sense.

Imagine this conversation between a patient and a doctor:

Patient: “My arm hurts.” Doctor: “What would you like me to do about it?” Patient: “Make my arm stop hurting.” Doctor: “Do you want me to cut it off?, I can do that.” Patient: “No, I just want it to stop hurting.” Doctor: “I could cut all the nerves to your arm. That’ll stop it.” Patient: “Isn’t there something less drastic you could do?” Doctor: “Ooops, sorry, time for my break.”

Clearly we don’t expect doctors to behave this way. Even though the patient is the boss, the patient expects the doctor to have the answers and help set the direction.

Here’s another version of the conversation:

Patient: “I want you to cut my arm off.” Doctor: “What’s wrong with your arm?” Patient: “It hurts. I’m tired of it. Just cut it off.” Doctor: “Let me see your arm. Hmmm. Looks like you’ve got a sprain or perhaps a hairline fracture. We should take some X-Rays.” Patient: “No, just cut it off.” Doctor: “Sir, I do not cut off healthy arms.” Patient: “But I’m paying you. You have to do what I say!” Doctor: “No, sir, I don’t. Cutting off your arm would violate my oath.”

Which of these two doctors would you rather be? Now project these two doctors into your own profession, and which would you rather be?

Programmers are professionals. They know more about designing and implementing software systems than their bosses do. Indeed, they are hired for this knowledge and expertise. And they have a solemn duty to prevent their managers from doing things that would be harmful.

All this boils down to one simple thing. Professionals are willing to say “No”. When their managers come to them with direction that makes no sense, a professional programmer will refuse the direction.

Is this risky? Sure. But part of being a professional is the willingness to stand on principle. There are lines that a professional will not cross.

Of course saying “No.” is only one side of the coin. Professionals are also expected to explain their positions, and come up with viable alternatives. Professionals negotiate with their superiors until both parties are satisfied with the chosen direction.

The poor web-designer schmuck in that cartoon was not behaving as a professional. He was behaving as a laborer. The fiasco at the end was his fault. He should have said “No.” and started a negotiation with his customer instead of just doing everything the customer said.

The cartoonist painted the web-designer as a wise but impotent victim, and the boss as the overbearing dufus. The reality is that the web-designer took the role of the victim voluntarily and shirked his responsibility to refuse direction that he considered harmful.

If you are a professional, you never allow yourself to be put in the role of the victim.

Several years ago (Pragmatic) Dave Thomas started a special blog about coding katas. The idea was simple: Professionals practice.

This thought might not have occurred to you before; but it’s self-evidently true. Professional musicians practice. Professional dancers practice. Doctors practice. Soldiers practice. Indeed, any kind of professional craftsman or artisan must practice their adopted trade in order to execute it well when it counts.

Dave’s point was that professional programmers need to practice like any other professional. He set forth a number of simple exercises and problems that programmers could solve during their practice time. He also suggested that practice time needs to be scheduled and protected as part of the normal routine of a software developer.

At XP2005 in Shefield, UK, I attended Laurent Bossavit’s and Emmanuel Gaillot’s Coding Dojo session. I blogged about it at the time. I left that session with a different view of what a Kata might be. In Dave Thomas’ view a kata is an exercise to solve. Each time you solve it you try a different approach. Dave’s notion is that a kata is a way to explore the solution space of a problem. But in Martial arts a kata is something different; it is a set of motions that one memorizes in minute detail. A martial arts kata is a precisely executed dance. I left Sheffield with the idea that a coding kata could be more like a martial arts kata.

About a year ago, Corey Haines (our wandering minstrel of code) stopped by and told me about some mini-conferences that had adopted the notion of coding kata. What he described sounded more like a group dance than a bunch of people independently solving a given problem. This got me thinking. So at the next Software Craftsmanship meeting at 8th Light (Which, not coincidentally, takes it’s name from a martial arts philosophy) I conducted a simple kata session in dojo style.

I, acting as the Sen Sei, had everyone file in to the room as they would to a dojo. I had them put their green bands on their wrists (mine was black!). I bade them to sit, and then gestured for silence. For the next 15 minutes I led them through the Prime Factors Kata in Java without uttering a word (well, almost). I would write a simple test case, then gesture for them to do the same. Then I would make the test pass, and again gesture for them to repeat my moves.

Then, this Fall, I attended Programming with the Stars at Agile 2009. As I watched the contestants perform their programming sessions, I realized that they were not simply demonstrating programming prowess; indeed they were competing in how well they performed their session. That’s when it struck me. This was a performance art!

It seems absurd to think of programming as a performance art. And yet watching those people up on stage working through routines that they had clearly practiced over and over again, was delightfully entertaining to me, and to the crowd. There were cheers and applause when a performing pair did something especially well. There was laughter when a pair executed a clever joke in code, or in behavior. For programmers, watching other programmers perform well practiced routines was fun!

Now I had seen martial arts katas executed as performance art during competitions. Indeed, it is a beautiful thing to watch a skilled and well practiced martial artist peform a kata. And that started me thinking. Why would a martial artist practice these forms so intensely that they could be performed as an art?

The goal of martial arts is not to perform on stage. The goal of martial arts is self defense! And yet, when a martial artist is at the peak of his skill, his practice takes on the quality of a performance art. When you watch a skilled martial artist perform, you know you don’t want to fight him. The performance is a demonstration, and a realization, of mastery.

And yet the performance is not the goal. No martial artist practices his art so that they can perform on stage. A martial artist practices to achieve personal perfection in the art of self defense. The fact that the practice can be performed is a (pleasant) side effect.

Could it be that these coding kata that we’ve been dabbling with for the last few years could be performed? Is there a benefit to practicing them so much that performance is an option? Is there really any reason for a programmer to create and then memorize a routine down to the level of individual keystrokes? Is there profit to be gained from practicing that routine so thoroughly that you can do it at high speed with virtually no errors? This August I decided to find out.

I started with the Prime Factors Kata in Java, and set it to music inspired by this video of dancing kites. The piece is about 4 minutes long, and I figured I’d need about twice that, so I found two different version of the music and played them back to back. But working in Java is ponderous, and I could not complete the kata before the two pieces had finished. So I switched to Ruby. Using Ruby and Rspec I was able to finish the Kata with plenty of time to spare.

Thereupon began an evolution. Since I had time, I added more features to the kata. As I improved in my practice I found I had even more time, so I added even more features. I refined and polished. I refactored my refactorings. I trimmed keystrokes, and learned many new keyboard shortcuts in the process. I completely abandoned the mouse; and then later reacquired it for flourishes and highlights (but never for actual coding).

Week after week, I set aside 30 minutes or so every day to practice, and practice, and practice—just the way I used to practice my Jiu Jitsu Katas. I would practice on airplanes while flying to clients. I would practice in bed with my laptop in my lap. I would practice late at night in hotel rooms after a long day consulting for clients. I would practice early in the morning before shower and breakfast. And the practice started to pay off.

Ten weeks later I finally decided I was ready to create a screencast. I reduced my screen resolution to 1024X768. I configured SnapZ ProX to record the whole screen at 80% size. And I began to record.

Performing a coding kata in time to music is a very difficult thing to do. Maintaining the timeline is critical. There are very few errors that you can effectively recover from. If you miss a stroke, the whole sequence melts down. And melt down it did. Over and over and over again. I spent weeks trying to record a reasonably good session. I must have done hundreds of takes. It was very frustrating.

But day by day I got better and better at it. Finally, after weeks of trying, I got what I consider to be a recording that, though not perfect, is good enough to present. You can watch that recording here.

Has this paid off in the regular programming I do? I think it has. My mouse usage is much less than it used to be. I know a much larger number of keyboard shortcuts than I used to, and I can use them almost instinctively. My typing and accuracy have improved quite a bit, and I now type more punctuation and number keys without looking. So, yes, I think the effort has paid off; though I’m not at all sure the payoff compensates for the effort.

But something else compensates for the effort. Making this recording was fun—it was a lot of fun. And that’s probably the real answer to the question posed in the title of this blog.

I participated in a simulation of a project, playing the role of customer.

• There were two of us playing customers – we did not understand the problem and we did not necessarily agree or understand where we had different interpretations
• We were freshly assigned the role and did not quite understand the details of the problem, our actual responsibility or how to interact with the team (a deficit of tacit knowledge)
• Time was (perceived to be) at a premium

The session/simulation was run with great expertise by Don Gray.

My first really strong observation was during the first meeting with the development group – about 5 minutes in. My co-customer and I had spent a few minutes (literally) reading the requirements and coming to some partial understanding. We met with the “simulated” development team and all hell broke loose (at least in my head).

The development team did some things well.

• They tried to think of something small they could do in a time-box.
• They presented us (the customers) with concrete examples of things they could do as first examples.
• They asked concrete questions about the requirements.
• The presented some preliminary examples of possible interpretations.

These are all good things; things I would and have recommend in the past – and will contine to do in the future. And these things did not work for me.

“Playing” the role of customer, when I came to that initial meeting there were many things in flux.

• I did not really have much of an idea of a time-box.
• I had looked at the problem in a very different way than the development team, so many of their questions simply did not make any sense to me.
• I felt bombarded by many voices, with many different kinds and levels of content.

I took away quite a bit away from that experience that I’d do well to incorporate in my future interactions.

• I am a big-time extravert (Jung’s definition) and I’ve been the source of this kind of bombardment.
• I need to catch myself jumping right in on what I think is important and instead ask what is important to the customer (or BA or QA or developer for that matter).
• I probably have overly high expectations of what can be accomplished before the team has started to form, much of that initial interaction lacks the tacit knowledge of actual roles and requirements, such that many things are in flux.
• Or, given a team that has been together, I need to get a grasp on its structure before making change recommendations.

At one point, someone mentioned (in essence) that the “actual” requirements were coming from Don, not me, and essentially wrote me off. That was quite a powerful experience as I felt completely devalued as the customer. I can imagine a business person or QA person feeling the same thing.

I think the biggest one-word summary of the experience for me is empathy.

“After” the simulation (I still had not fully decompressed I think), one person expressed concern over how the customers (me) had not followed “the process”. Wow is all I can say to my experience during that simple, loaded phrase.

In my world of the simulation, there was no process – explicit or implicit. If there was one used by the team, it was tacit and I certainly was not aware of it (in fact, I don’t think there was one “the process” as far as I could tell because I was able to both participate and observe). But regardless of whether there was or was not an explicit or implicit process, it does not matter. Can you imagine someone who is not fully available (a customer), being treated as if they were “not following the process?”, which I inferred to mean “I was being difficult.”

When I’ve thought that, consciously or even subconsciously, I’m certain that belief clouded my interactions with other people and it probably has come across as aggressive/offensive/inconsiderate. Maybe a good mantra to repeat to myself is something like:

No matter how it might look, people are trying to be helpful to the best of their ability.

I know for certain my intentions during that simulation were good. I was trying to give information to the best of my abilities. I just wasn’t yet aware of the requirements and I did not know how the development team was working. To be treated as if I was sabotaging “the process” was in fact quite offensive to me. I am certain I’ve done that over the years. “The process”, regardless of which process it is, is a model of how to do things. And something I overheard really speaks about this:

All models are wrong; some are useful.

(Notice how that applies to things like TDD, BDD, Scrum, XP, ...?-)

If you have a chance to attend AYE next year (or PSL in May), I’d encourage you to do so. But be prepared to be overwhelmed with personal observations.