Last week a colleague and I held a presentation about TDD for some of the developers at one of the largest banks in Norway. It was a 3 hours session with a mixture of presentation and 3 demos. The presentation can be viewed here. Here is a quick summary of the contents of the session:
The session was split into three parts:
1) TDD intro – What is it and why should you use it
2) Beyond TDD – Why supplementary techniques is needed
3) TDD in “real life”
The first part was an introduction to TDD, in essence: What is it and why should we use it. This first part was rounded up with a small TDD demo which showed how to employ the practice for development of a small CSV parser. The intention was to give an example closer to the real world than the “standard” calculator example. I think this worked pretty well even though I had some “finger-trouble” with the keyboard on a laptop I was rookie enough to not try in advance. Three major learning points from holding this live demo:
1) Always use a keyboard you are familiar with
2) Favor short descriptive names on classes, methods and variables instead of long ones. This will improve your speed and make the flow better
3) Your demo will always take longer time than expected. If you accept questions from the audience along the way, you should multiply your time estimate with 2, at least
In the second part of the session, our primary message what that TDD alone is not enough. You also need something more if you want to make sure that you deliver the right code right. TDD helps you in creating the code right and to some extent it is also an aid in creating the right code. However, since TDD is a development practice and part of the programming cycle, you may end up with the “wrong” code being developed. Research has shown that approximately 56 % of all errors in software comes from the requirement. Take this into account and it is quite clear that you need something in addition to TDD that can bridge the gap between the functional and technical level. We truly believe that acceptance test driven development (ATDD) can be a valuable practice to bridge this gap. The second part was concluded with a demo showing Fitnesse as an acceptance testing framework and an agile ecosystem consisting of the former, Eclipse, Maven2, Trinidad, Hudson and Nexus.
In the third and final part of the session we wanted to focus on how to use TDD in real life. That is: What do you do when you are up to your knees in legacy code and struggle to get your code base under test? We presented some important programming principles like dependency injection, program by interface and mocking before we moved on to a demo showing how to get some legacy code under test. We showed how to mock an external dependency and also presented some “Michael Feathers techniques” like “Introduce static setter” and “Subclass and override method”.
All in all I think that we succeeded quite well with distributing our message: To make the right code right it is important to apply several agile practices. TDD is an extremely valuable technique to drive the development and the design, but it should be complemented by techniques like f.ex ATDD.