November 12, 2013

...Learn TDD with Codemanship

The Tail Wagging The Dog - Why You Should Start With Examples

If you're one of those enlightened teams that agrees executable acceptance tests with your customer before writing software to satisfy those tests, how do you do it? Or, rather more importantly, when do you do it?

I observe on most teams that acceptance tests - examples of how a feature will be used - are based on a user story.

e.g., "As a business traveler, I want to search for hotels in a given area that have certain amenities with rooms within my budget" might yield tests like "Bill is looking for a hotel with free wi-fi within 1 km of Earls Court that has rooms for under £120 a night" and "Joanne is seeking a hotel with a gym and a swimming pool in central Manchester for under £140 a night"

Here's the thing with that; countless times I've found software I'm using doesn't quite let me do what I need to do. There's usually some detail they've overlooked that makes the software less useful in the real world. For example, travel web sites that don't let me know how fast the wi-fi is in the rooms. That's actually important to me. I work a lot in hotels, and wi-fi is often a bugbear. If it's slow and sluggish, or if the signal doesn't quite extend to the desk they've thoughtfully bolted to the wall so I end up having to check my email in the shower because that's where I can get a signal, well, it's a consideration.

So, "How fast is your wi-fi?" is a question I'd like to ask - I suspect many of us would - but the web applications for finding hotels don't let me.

Let me give you an example that's closer to home; unit test frameworks. So, I'm delivering a TDD training course for Acme Plc (name changed to protect the innocent), and they're stucking using Microsoft's proprietary unit testing tool. And we get to that part of the workshop where I'm asking them to refactor duplication out of their tests, and I innocently say "try turning your tests into one parameterised test" and they all put their hands up and say "Our tool doesn't support parameterised tests!"

WTF, Microsoft? That comes up often when writing unit tests. It's a powerful way to reuse test code and remove duplication. It can be an efficient way of getting better test assurance. If the tool designers had actually watched teams doing unit testing for any length of time, they would surely have spotted this need eventually.

I'm sure you can think of many examples from your own experience of software that appears to have been designed by people who didn't understand the problem they were trying to solve.

Because of this, I strongly recommend that teams begin by harvesting examples from the real problem domain. So "Bill is looking for a hotel with free wi-fi within 1 km of Earls Court that has rooms for under £120 a night" would be a real example of a business traveler looking for a hotel. (Or, indeed, "Jason wants a hotel that has a minimum 2Mb wi-fi connection with a strong signal at the provided work desk in the room").

Examine these examples, recreate them, live them. Only when they've sunk in should we look to generalising them into formats like "As a business traveler..."

Any scientists will tell you of the dangers of seeking data to prove your theory. A true scientist seeks a theory to explain the data.

Posted 7 years, 1 month ago on November 12, 2013