Skip to content
Tags

, ,

Thoughts on: “Dan North: The Art of Misdirection”

by on June 13, 2012

Dan North published a very interesting to read and well written article “The Art of Misdirection”. It tells about the the opportunity costs of different development approaches from the testing perspective, where the leading question is: “What could you have done instead?”

Why is this article so appealing to me? I am a tester and I am supporting teams at CoreMedia in their testing efforts – so you might call me a testing evangelist. In addition I studied computer science with focus on neural nets – so if I read of local maxima where you get stuck I know what it means. And I am taking part in Code Katas at CoreMedia where we just practiced a Code Kata which totally matches to the claims of the article.

Short Summary of Dan’s Article

Let me give you a short summary of Dan’s Article. Although I really recommend reading the article as it is fun and easy to read as it doesn’t come with too many technical terms.

The question which hovers above the whole article is “What could I have done instead?” What could I have done instead developing with test-first? What could I have done instead writing automated tests? And it opens the eyes on observing the non-obvious, that is it suggests to take a step back sometime and look at what you’ve done and value if it is good or if there are better alternatives.

The hidden cost of software development is the eye-opener. If you have a well trained practice and value it as best practice: take a step back and see what alternatives you might have missed.

TDD under the spotlight is teaser for all TDD evangelists. Do you like test driven development? Do you dogmatically enforce your team to do TDD? You shouldn’t tear this article into pieces – but start reading and understanding it.

The opportunity cost of stead, confident change draws an example where TDD might cost too much. This is when you are drawing (implementing) sketches of your software and then again throw away some sketches just to draw new ones. In TDD you would not even throw away your sketches, but your tests, too.

The opportunity cost of emergent design introduces two Lean terms, kaizen and kaikaku:

In Lean terms this is the difference between kaizen, continuous improvement, and kaikaku, abrupt transformation.

And it tells about software trapped at a local maximum because of kaizen approach while the global maximum can only be reached through kaikaku.

The opportunity cost of automated tests again tells that you should always keep the alternatives in mind. Especially for automated UI tests which cost a lot (compared to Unit tests) you should always evaluate the alternatives.

The opportunity cost of tests as living documentation values tests as part of the documentation. But sometimes also as documentation of the history for example a test for BUG-123 This should not do that – and ten years later you read this and say: No, of course it should not.

Code Kata: Red Pencil Promotion

We recently trained the Code Kata: Red Pencil Promotion introduced by Stefan Roock in 2011. We had two different approaches between the pairs. One took the whole story to implement what the customer needs, and the other did it step by step – each step thoroughly tested before going to the next.

I took part in the second approach. We decided to be blind for the subsequent requirements, implemented the first feature test driven, got to the next and so on. At one point (“A red pencil promotion lasts 30 days as the maximum length.”) we got trapped. The trap was the one described by Dan: We could not go further without either tweaking (kaizen) or to do the breaking change (kaikaku).

We decided to do the breaking change – and we actually had to rewrite all tests. The only thing that was stable was the test name as we decided the test names to state the requirements tested and not to name for example corner cases.

Developing a UI Testing Framework

I am currently developing a testing framework for UI tests where I made a similar experience as from the code kata: I followed the kaizen approach to develop the framework from scratch. I decided for a certain pattern to wait for UI states derived from the approach as Selenium WebDriver waits for UI states. So I thought I was using a good pattern.

At some time during development I reached the state where I could not go further. I had the option to give developers a testing framework where they need to learn a lot – or to put all code into the trashcan and restart the whole approach.

I decided for the latter one. I had the feeling to do something bad as it also meant that I “throw away paid time”. Nowadays I can say that it was a very good decision to throw away the code as the new waiting pattern is adopted very well by our developers – and as a result it even saves development time.

Two things were important here: The decision itself that it is absolutely ok to throw away the old code – and customer feedback. I presented the testing framework again and again to our developers which are actually the customers of this framework and their feedback lead to the conclusion that a refactoring is required.

Tests written in Gherkin Syntax

As Dan suggests I am not dogmatically following approaches like TDD or BDD (behavior driven development) but try to choose the approach with the best cost-benefit-ratio.

But what I learned from the Code Kata and from the UI Testing Framework Development is this:

Tests should be written at top level as you would have written a good documentation.

The way we are taking now is to write tests using the Gherkin Syntax for the test body. And to stay closer to the needs of the developers we use plain JUnit and don’t use frameworks like Cucumber or JBehave. So a test might look like this:

@Test
void scenario_document_creation_wizard() {
 given_I_am_logged_in_as_editor();
 when_I_open_the_the_document_creation_wizard();
 then_I_want_to_be_able_to_create_a_document_just_choosing_its_name_and_path();
}

The art of this approach is to write the test body in a way that it is unlikely that you will ever need to refactor it.

This approach is the result of considering the opportunity costs again and again. We first joined the JBehave train, then stopped to see what we gained and what we lost. Then we decided for this approach – but of course, as Dan suggests, I expect that this is not yet the global maximum to reach. So perhaps some day it is time for a change.

From → Agile, Dev, Testing

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s