Category Archives: TDD

Test-Driven Development

How big are your steps?

I re-ran my An Introduction to Test-Driven Development session yesterday…to an exceptionally interactive and responsive audience.

The slides are free to download here (1134k). Feel free to download the Delphi 5-7 code, the Delphi 8 code or the Visual Basic.net code.

I was using DUnit with Delphi 7. I re-iterated the fact that eXtreme Programming and TDD extol the virtues of “doing the simplest thing that could possibly work”.

Read more about the session here.

Tied in with this debate was a lengthy discussion about the concept of “small steps”.

Early on in my session I took lots of really small steps, panicking the audience slightly as they wondered how long it would take me to get from 1 to 2000 in Roman numerals (I was applying TDD to a Roman numeral conversion class).

TDD promotes the notion of taking plenty of small steps, gradually taking slightly larger steps as your confidence increases. However, the instant you step over your mark and take a step that’s too large, you should revert to taking smaller steps until to regain your confidence.

The size of TDD steps is important and it’s one that you have to be happy with yourself: a “small step” that works for you might be a large step to somebody else. It’s about finding a happy medium – go out and try TDD for yourself, make the mistakes that I did, take large steps, try to do too much in a method and test. It’ll all come out in the wash and eventually as Erich Gamma said, you’ll be “test infected

Want to learn more about TDD? These books are highly recommended:

Test-Driven Development in Microsoft .net
Test-Driven Development: a practical guide

Test-Driven Development: a practical guide: Reviewed here.

Test-Driven Development by example

Doing “the simplest thing”

I re-ran my An Introduction to Test-Driven Development session yesterday…to an exceptionally interactive and responsive audience. The slides are free to download here (1134k).

I was using DUnit with Delphi 7. I re-iterated the fact that eXtreme Programming and TDD extol the virtues of “doing the simplest thing that could possibly work”.

About half way through my session (which could easily have run on to 2 hours had dinner not got in the way!) a well-respected friend, Adrian, raised his hand and said: “Building a class isn’t the simplest thing!”

I had built a class that converts integers into Roman numerals. The first step was to add a method, toRoman, that took an integer and returned nothing. The second step was to have it return ‘I’ when ‘1’ was passed in as a parameter. Feel free to download the Delphi 5-7 code, the Delphi 8 code or the Visual Basic.net code.

Of course, he was right, building a class that has one method returning the letter ‘I’ is overkill. It’s not the simplest thing. Everybody knows that the simplest thing would have been a simple function with no class wrapper and no hint of object-orientation.

I realised that what I had done was the simplest thing the could possibly work in this xUnit testing framework. It wasn’t the simplest thing that might get the job done.

Similarly, in an earlier re-run of the same session, Andy, pointed out that my idea of the simplest thing perhaps wasn’t his. And herein lies one of TDD’s ironic facets: whilst TDD provides us with a great understanding of “how” a piece of code should be invoked, thus increasing the chance that somebody other than the original developer/programmer will be able to understand it, TDD can be an emotive process.

TDD will help you as far as your “under the bus count” goes, it will give you the most accurate form of documentation that you’ll ever have for your code base, but it won’t help you ring fence or blinker your programmers in to writing code the in the same way. But, since that’s not something any of us should relish, Borg-like programmers churning out the identical code for the same problem, it shouldn’t put you off TDD.

I’ve just googled under the bus count only to realise that it’s not defined anywhere.

I’m using the phrase to mean:

    the number of people on a project who need to be run over by a bus, that will then make the project fail or incur a severe cost/time delay

If you are on a project with a team of one: yourself, then the under the bus count is one. If one person, you, is run over by a bus, the project fails, or meets almost insurmountable cost/delays. Of course, if it’s just you on the project team, you probably don’t need to worry about who’s going to be picking up the project after you’re gone!

Ideally, you should try to drive your under the bus count upwards, away from one. There should be no single point of failure, no empire-builders.

Go practice TDD, trust me, it works. It heralds a new confidence that will allow you to improve (refactor) huge chunks of your code base that you’d probably never want to touch citing “if it a’int broke don’t touch/fix it”…when you know perfectly well that the internal design is like a house of cards and won’t survive the next bout of customer change requests. It improves the quality of your life…there, what else goes this far?

Want to learn more about TDD? These books are highly recommended:

Test-Driven Development in Microsoft .net
Test-Driven Development: a practical guide

Test-Driven Development: a practical guide: Reviewed here.

Test-Driven Development by example

Test-Driven Development: a practical guide – book review

Test-driven development (TDD) has become very popular in recent months. Until now there was only one textbook on the subject: Kent Beck’s. “test-driven development: A Practical Guide” by David Astels, was published in July 2003 and complements Beck’s original TDD work. This book is part of The COAD Series, named after Peter Coad, Borland’s Senior Vice President and Chief Strategist. The book itself is a little over 550 pages long and offers up-to-the-minute advice on how TDD can change your development and testing philosophy.

Read the review here.