Navigate / search

Test Driven Development – Pushing Through The Pain

Sample Code
TDD Sample Code for DDD South West

Last weekend I presented a session on Test Driven Development at DDD South West in Bristol. I actually presented the session twice thanks to being voted onto the repeat track, and in total I had 120 brave souls who came along to see the session.

I’ve taken the past week to go back over the sample code that accompanies the session and tidy it up a bit, add some ‘discussion’ comments about various issues, and also factor in a few suggestions that I received on the day.

The code can be downloaded from the link at the top and bottom of this post. The slides can be viewed here:



Thanks to everyone who came along, that especially to everyone who left feedback, and virtually everyone did. This session started with a 90 minute running time, I cut it to 1 hour for DDD South West, but it still felt a little rushed. My hope is to cut it dramatically in time for DDD North (if I’m fortunate enough to be invited) and cover less ground, but in more detail and with more time for interaction and questions from the floor.

If you have any problems with the code, or if you’d like to point out some issues with it then leave a comment or find me on twitter (@richardadalton).

Thanks for stopping by.

Sample Code
TDD Sample Code for DDD South West

Retro Fitting Unit Tests to Legacy Code

This post references a StackOverflow thread which you can read
here

One of the problems with TDD is that those who try it, often begin by booting up NUnit or something similar, writing a few trivial tests to get the lie of the land, then instead of doing TDD (i.e. Writing a test and then writing some code to make the test pass) they do something much much harder, under the mistaken impression that it will actually be a way to ease themselves into TDD.

They do what I did, they start out by trying to write some unit tests for existing code. Either a past project, or more likely the project they are currently working on. They quickly discover that these projects are (from their perspective) virtually impossible to test.

The reason why is obvious, 1) They are new to writing automated tests, which is a tricky enough skill to master, but more importantly 2) They are new to writing testable code which is actually a significantly bigger challenge than writing tests. The chances that their old projects contain testable code is virtually nill.

So, our protagonist is actually starting their journey to TDD with an obstacle that is actually beyond the ability of some seasoned TDD practitioners. Think a video game with the ultimate Boss level as the very first thing you do, before you learn the controls or understand much of anything about the game. That right there is a game that you’ll probably throw in the bin after about an hour, if you last that long.

In my research for my TDD session at #dddsw I found lots of interesting questions, blogs and articles, most of which I didn’t have time to fully discuss during the session, but I’ll point you in the direction of some of them over the next few days/weeks.

The first is a Stack Overflow discussion on how to write automated tests for a complicated function with lots of dependencies.

It’s notable because it’s not an uncommon problem, and the answers cover the usual spectrum from practical solutions to pragmatic advice to questioning the validity of the original question etc.

It’s also notable because Uncle Bob contributes an interesting Step By Step on how to add tests to existing code (in an kludgy way) and then how to refactor both the original code and the kludgy test handling.

Original Thread Here

Enjoy.