Recycling tests in TDD

The standard way that TDD is described is as Red-Green-Refactor:

Red: write a failing test
Green: get it to pass as quickly as possible
Refactor: improve the design, using the tests as a safety net

TL;DR; I’ve found that step 1) might be better expressed as:

Red: write a failing test, or make an existing test fail

Print Diamond
One of the katas that I use in my TDD training is “Print Diamond”. The problem statement is quite simple:
Given a letter, print a diamond starting with ‘A’ with the supplied letter at the widest point.

For example: print-diamond ‘C’ prints

 B B
C   C
 B B
I’ve used Cyber-Dojo to demonstrate two different approaches so you can follow along with my example, but I recommend you try this kata on your own before reading further. .
The usual approach is to start with a test for the simple case where the diamond consists of just a single ‘A’:
> PrintDiamond(‘A’) 

The next test is usually for a proper diamond consisting of ‘A’ and ‘B’:
> PrintDiamond(‘B’)

It’s easy enough to get this to pass by hardcoding the result. Then we move on to the letter ‘C’:
> PrintDiamond(‘C’)

 B B
C   C
 B B

The code is now screaming for us to refactor it, but to keep all the tests passing most people try to solve the entire problem at once. That’s hard, because we’ll need to cope with multiple lines, varying indentation, and repeated characters with a varying number of spaces between them.
The approach that I’ve been playing with is to start as usual, with the simplest case:
> PrintDiamond(‘A’) 


For the second test, however, we start by decomposing the diamond problem into […]

By |November 23rd, 2014|BDD, Cyber-Dojo, Practices, TDD|12 Comments

User Story Mapping

I’ve been reading Jeff Patton’s work online for years, learning from his ideas and approaches. You’ve probably come across his Mona Lisa analogy for iterative and incremental development – and if you haven’t this is a good time to go and read it 😉

Well, he has just released a book, User Story Mapping, and it is every bit as good as I would have hoped. If you don’t know what User Story Mapping is then this book will (obviously) tell you, but you will learn a whole lot more than that. I believe that this is THE missing agile book.

Throughout the book Jeff uses examples from his clients to demonstrate the simple techniques that he uses. ANd the most important ingredient, for me, is the emphasis on the need for rapid feedback and the need to SLICE USER STORIES THINLY. He’s not alone in this regard – JB Rainsberger calls it “Product Sashimi” and Alistair Cockburn calls is “Elephant Carpaccio”.

Go buy this book today. Don’t let it languish on your bookshelf – read it. And start putting the advice into practice as soon as you can.

By |November 17th, 2014|Agile, Practices|1 Comment

Using SpecFlow on Mono from the command line

SpecFlow is the open source port of Cucumber for folk developing under .NET. It has been compatible with Mono (the open source, cross platform implementation of the .NET framework) for several years, but most of the documentation talks about using it from within the MonoDevelop IDE. I wanted to offer SpecFlow as one of the options in Cyber-Dojo and, since the Cyber-Dojo IDE is your browser, I was looking for a way to make it all happen from the command line.

Cyber-Dojo already offers C#/NUnit as an option, so I used this as my starting point for making SpecFlow available. I came up with a list of tasks:

Install SpecFlow
Generate ‘code-behind’ each feature file
Include generated code in compilation

Install SpecFlow
I found an interesting website that had detailed instructions for installing SpecFlow on Mono. There don’t seem to be any handy ‘apt-get’ packages, so it is basically a process of downloading the binaries and installing them in the GAC, for example:

  gacutil -i TechTalk.SpecFlow.dll
Generate ‘code-behind’ each feature file
SpecFlow ships with a command line utility, specflow.exe. I tried following the instructions from the article that had helped me with the installation, but they didn’t work for me. I ended up invoking the utility directly:

  mono ./specflow.exe

Running specflow.exe like this lists the operations that the utility provides, from which I chose ‘generateall’, because (according to the documentation) it should do exactly what I want:
re-generate all outdated unit test classes based on the feature file.
Unfortunately it needs a Visual Studio project file (csproj) as input, and since we’re not using Visual Studio we don’t have one. This led me to insert a fourth item in my task list: “Create csproj file”
Create csproj file
I started with an MSDN article that describes creating a minimal […]

By |October 5th, 2014|BDD, Cyber-Dojo, Practices, TDD, Unit testing|1 Comment

The most important change you can make to help your team succeed

How busy are you?
Are you close to a deadline? Is the team feeling pressure? Every team I visit seems to be under the same heavy workload, and consequently has a lot of improvements to the process, the environment, the technology that they can’t quite get to yet. They know they need to get to them, and they will…. when they have time.

But they won’t get time.


TL;DR: Build slack into your iteration

The nature of time
When I started trying to write a book I spoke to a colleague, Jon Jagger. I whined that I just didn’t seem to be finding the time and he replied with wise words: “You won’t find the time. You’ve got to make the time.”

The same is true for any tasks that support the development team that don’t obviously deliver immediate working software for the customer. The reasons for this are many, but the root cause is normally disempowered teams. Teams who ask their product owner to prioritise tasks that the product owner has no way of prioritising appropriately. Most POs should not be asked to choose between a user story that delivers a feature they understand and a technical task that they don’t. It’s a no-brainer – they’ll always choose the user story to maximise customer value. Even if the technical task will actually deliver greater customer value.

Before I continue, I’d like to remind you of two things: sustainable pace and commitment
Sustainable pace
The agile manifesto is quite restrained in its pronouncements. One of the 12 principles it states is this: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” This doesn’t mean we don’t work hard. It doesn’t mean we never come in early, work […]

By |April 30th, 2014|Agile, Practices|2 Comments

5 rules of continuous delivery

Inspired by Sandi Metz’s BaRuCo 2013 presentation “Rules” (which you should watch if you haven’t yet) I started thinking about whether there were some  rules that might be useful in the continuous delivery domain to “screen for cooperative types”.

I came up with these as a starting point:

Check in everything – we’re used to putting source code in version control, but we’re often less good at configuration management. Do you control your test data? Your database scripts? Your operating system patch level? If not how can you be sure that the environment you provision tomorrow will be identical to the one you provisioned last week?
Automate everything – “to err is human”, as the saying goes. Any manual process is susceptible to failures, so get rid of as many as you can. Some continuous delivery pipelines still have manual approval steps in them as part of the process, but the presence of the human is not functionally essential.
Continuous != occasionally – the more we do something, the easier it gets. One of the reasons to do something continuously is to decrease the cost and remove the fear. If it “costs too much” to deploy often, then work on reducing the cost not reducing the frequency.
Collaborate – people are not plug compatible. To get the most from the different people in the organisation we need to work together. For me, this was one of the major “innovations” of devops – no more ‘us’ and ‘them’, just ‘we’.
One step at a time – it’s hard to do everything all at once, which is why we iterate in software development. Continuous delivery is no different – don’t expect everything to “just happen”.

Do these make sense to you? What essential ingredients have […]

By |February 28th, 2014|Agile, Continuous Delivery, Practices|3 Comments

Continuous delivery – the novel

I find myself recommending the same books over and over again. When speaking to techies I invariably recommend GOOS; when speaking to managers The Mythical Man Month or Waltzing With Bears. Over the past year or two, I’ve also pointed a lot of organisations at Continuous Delivery by Jez Humble and Dave Farley. It’s an important book, but I think it could have been shorter, and that’s an important consideration for the target audience. If you consider the other books I recommend that weigh in at 384, 336 and 196 pages respectively, Continuous Delivery extends to 512 and it feels longer. That’s not because it isn’t good – it is – but because it is detailed and quite dense.

Last week I finally heeded Liz Keogh’s advice and read The Phoenix Project (“a novel about IT, Devops and helping your business win”). In terms of prose style, it doesn’t compete with Liz’s own efforts, but it is very readable and does a great job of getting some quite tricky concepts across (Lean, Theory of Constraints, The Three Ways). The authors acknowledge their debt to Goldratt’s The Goal, and indeed they are ploughing the same furrow, but in the field of software. Amazon says the print copy is 343 pages long, but I read it on the Kindle and it felt shorter than that.

The reason I’m adding this book to my recommended list isn’t just because it’s short and readable. It’s because it makes some very frightening concepts very easy to digest. I didn’t know how to explain quite why I liked it so much until I found myself reading a Venkat Rao post this morning, where he describes how we change our minds:

You have to:

1. Learn new […]

By |February 24th, 2014|Agile, Practices, Systems|1 Comment

Teaching TDD (TTDD)

There has been a flurry of discussion about how to teach TDD, sparked off by a recent post from Justin Searls. In it he lists a number of failures that range from “Encouraging costly Extract refactors” to “Making a mess with mocks” all of which distract attention from the concept that “TDD’s primary benefit is to improve the design of our code”. He concludes by suggesting that once you have written a failing test, rather than get-to-green in the simplest way possible you should “intentionally defer writing any implementation logic! Instead, break down the problem by dreaming up all of the objects you wish you had at your disposal”. In essence, design the elements of the solution while the first test is still red.

It’s an interesting post that raises a number of issues, but for me its value lies chiefly in opening the subject up for debate. The introduction is particularly pertinent – just setting a class a bundle of katas to do does not, of itself, encourage learning. The pains experienced while doing the exercise need to be teased out, discussed and have alternative approaches described. If you don’t hear the penny drop, then it hasn’t dropped.

Pitching in with characteristic vigour and brimstone came Uncle Bob with a robust rebuttal containing both heat and light (though some have been put off by the heat and never got to the light). Bob makes some good points regarding the fallacy of writing tests around extracted classes, the tool support for extract refactoring and the central place of refactoring in the Red-Green-Refactor cycle.

By the conclusion, however, Bob has switched tack. He states that while refactorings are cheap within architectural boundaries, they are expensive across them. Whether he’s right or wrong […]

By |February 4th, 2014|Practices, TDD, Unit testing|2 Comments

Eat your own dogma food

The software development community experiences fad after fad. Consultants and thought leaders dream up new methodologies; old practices are relabelled and promoted as the next big thing; flame wars are fought over names, tabs and brace position.

One of the few practices that has stood the test of time is that of “eating your own dog food”, which essentially means that you’ll be the first user of any software that you’re developing. In more polite (and optimistic) circles this is also known as “drinking your own champagne”. When it comes to development practices, I think we need to adopt the same approach.

If you’re going to make dogmatic statements about how software should be developed, then you as a developer should be prepared to stick to them yourself. No more  “do as I say, not as I do”. It’s time to eat your own dogma food.

By |January 14th, 2014|Agile, Practices|0 Comments

TDD at interviews

Allan Kelly posted an article on DZone this week predicting that TDD would be a required skill for developers by 2022. Vishal Biyani asked on Twitter about how one might test TDD skills, and I promised to blog about my experience of using Cyber-Dojo in interview situations.

Cyber-Dojo is a browser-based dojo environment developed by Jon Jagger that supports a lot of programming languages and xDD frameworks. It’s great for dojos because it has few of the productivity frills that we’ve come to depend on over the years – no syntax highlighting; no autocompletion; no suggested fixes. That means we have to think about what we’re doing, rather than relying on muscle memory.

As Jon eloquently puts it in the FAQ: “Listen. Stop trying to go faster, start trying to go slower. Don’t think about finishing, think about improving. Think about practising as a team. That’s what cyber-dojo is built for.”

That might be what cyber-dojo was built for, but it turns out that it’s also excellent as an interview environment. Your interviewee writes real code and has to diagnose with real compiler/runtime errors. They’ll have to use a browser to remind themselves of all the basic knowledge that has atrophied during years of nanny-IDE development. And, best of all, there’s no save, build or run functionality provided by cyber-dojo. There’s only a single button and it’s labelled nice and clear: TEST.

Use one of the katas whose instructions have been helpfully included with cyber-dojo, or roll one of your own, and see how your interviewee responds. Every time they press the TEST button, all the code they’ve written is sent over to the server to be built & run and the response is returned, along with a traffic light: green for “all tests passed”, red for […]

By |January 11th, 2014|Practices, TDD, Unit testing|1 Comment

When is a tester not a tester?

No, I’m not trawling through my xmas cracker jokes. I was looking through the programme for DevWeek 2014 and both my sessions are tagged as “Test”. This is following a pattern started at ScanDev last year and followed by several other conferences at home and abroad.

Why am I bothered? It’s not that I mind being associated with testing at all. I don’t think of testers as a lower form of life. I *love* testers. It’s for the same reason that Dan North and Chris Matts started using the “should” word instead of the “test” word all those years ago – developers think that the test track is not for them.

Both my sessions at DevWeek are about types of testing that developers should be doing routinely. “So long, and thanks for all the tests” explores what makes a test valuable and what practices developers should consider adopting. “Mutation testing – better code by making bugs” is an alternative to code meaningless coverage metrics that can help developers ensure they’re sticking to their definition of done.

Q. When is a tester not a tester?
A. When they’re a developer.

You’re right. It’s not funny. So, it’s ideal for a cracker.

By |January 9th, 2014|Practices, Unit testing|0 Comments