An introduction into the TDD Mantra

A while ago I gave a presentation, called “An introduction into the TDD Mantra”. The occasion was a technical meeting with some colleagues, to whom I wanted to introduce at least the principles behind Test-Driven Development.
A lot of people think TDD is the same as writing unit tests, but it is not. That’s why I wanted to explain it to people. Dan Bunea also has an article about it right here, and it seems he’ll continue this with more stories about how to do it.
My presentation slides are a more high level introduction with some statements that should trigger people to start thinking about Test-Driven Development. The part I liked most was the part where I wrote an application live, using TDD of course. You might recognize it as Robert ‘Uncle Bob’ C. Martin’s Bowling Kata. I ‘translated’ it into C# with an accompanying document to check if you’re doing it right. It seems Uncle Bob has done it hundreds of times over the years, I’ve done it 7 times or so now. Not once completely without errors. But that’s not bad, it’s fun to solve these in front of a live audience. And they’re just minor errors.
I also try to explain what Dependency Injection is, with some examples in code. Then a nice bridge to legacy software, in which I ask what legacy software is. It concludes with a great statement from (a colleague from) Michael Feathers, and that you should start writing unit tests immediatly, doing it the right way with Test-Driven Development.
Update: Fixed the broken links

You may also like...

14 Responses

  1. Dan Bunea says:

    Hi Dennis,

    I really like your presentation, as it is simple and it touches all that needs to be touched about TDD.

    For dependency injection/Invertion of control I use Windsor, from, as well as MonoRail (a Ruby on rails .net port) and ActiveRecord (on top on NHibernate, and AR implementation) all developed by the same castle extraordinary team. All are developed using TDD, and make TDD easier. The amount of code compared with ASP.NET/ADO.NET is much less and much simpler. I hope to be able to write a small article about using MonoRail and implementing TDD on web applications using Selenium ( )


  2. Hi Dan,

    Thanks for the comments. In the talk I’ve spoken about options as frameworks for mocking. I’ve also touched IoC and stuff. But I only had an hour or so, with the coding taking up half an hour.

    Initially I had the MVP pattern shown with DI, but in front of a test audience, we decided this was too much. So I changed it into a simple business and data object and I had already decided not to touch a lot of those other topics.

    Personally I’m definitly still learning a lot though, especially from posts like yours.

  3. Patrick Wellink says:


    Does this apply to a BizTalk solution as well ?
    I find it really hard to place BizTalk inside a kind of unit test.

    Cause a unit tests a small unit of work, but hjow do you write a unit test for an orchestration (or a series of related orchestrations)

    Does unit testing apply at all to a BizTalk solution ?

    Patrick Wellink

  4. Patrick,

    I have no idea how BizTalk orchestration works. But think about a database. When you start automated testing your database, you also have to make sure there’s some fixed data, when retrieving it. If you do something like select x from tableA where y = 2005 then you have to know what is returned.

    The same probably goes for BizTalk. When you insert something, you should know how things will pass through the system, with or without (complex) orchestration.

    TDD principles are however about test-first. So when you want to insert something into BizTalk, you should write a test first, and then think about how to implement this in BizTalk. I’m not sure if this is as possible as with a database, for example.

  5. Patrick Wellink says:

    Well dennis,

    That’s the problem i know there are people out there that think that you should test a BizTalk solution.
    But the problem is….

    A bizTalk orchestration is Quite a Big unit, it’s not like a function but more a complete library. So with 6 orchestrations you can build quite a complex solution.

    So my problem is how big can a unit get before unit testing becoms integration testing…. ( cause that’s what i think i should do…)

    Furthermore it is almost impossible to test an orchestration… Since we are dealig with XML you cannot test all instances of the XML. We can try a couple that will trigger the happy flow and a couple that trigger the unhappy flow but that’s basically it…..

  6. Sam Gentile says:

    Hi Dennis,

    I took a quick look at the deck and you did a good job.

  7. Testing BizTalk ís integration testing. It crosses a major boundary! But this doesn’t (have to) mean you cannot test it with nUnit, VS2005 Team System or anything else.

    And 6 or 100 orchestrations, my custom code can in theory be a thousand times more complex. And if code is testable, orchestrations are testable as well 🙂

  8. >I took a quick look at the deck and you did a good job

    Thanks, good to hear I’m not that far off the mark anymore! 😉

  9. Shawn Lauzon says:

    I’m so glad I found your presentation! I would like to take it, make a couple changes, and present it to a group at work (with proper credit of course!) That ok with you?

    Also, I think a good addition would be an example of using a mock object; I added a slide with jMock in my own version.

  10. Shawn, sure you can. I’d love to see what you’ve changed, especially the mocking stuff! If you can, send me an email via the contact page. I’m not that happy displaying me email address here for all bots to take and spam me crazy. Thanks

  11. Julian says:

    Seeing the comments I think I would like the presentation as an inspiration for my presentation this week, but I cant download it could you send it to me? [email protected] is my e-mail box

  12. Raul Macias says:

    I am new to TDD and I’ve found your presentation very helpful. Thanks!

  13. No problem, glad people still find my stuff helpful! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *