Geeks With Blogs
Lee Brandt's Blog You're only as smart as your last line of code
I'm test-driven!I am pushing myself down the TDD path. I say pushing because it is definitely a hard row to hoe. I'm not used to the test-first paradigm. I am getting better, but the purpose of this post is to talk about some of the benefits I have reaped from TDD, and help myself (and hopefully others) to learn why test-first development can help you code and your design.


Obviously, if you are writing a failing test, writing code to pass the test, confirming this every step of the way and your code coverage is good, then your code will be more stable. That doesn't mean it will be elegant or take the best approach, but it passes your tests. If your tests are good, then your code will be more stable.

Accountability gm_test_500

Writing the tests first allows you to see the desired end result as a list of tests that must pass. This allow you to account for completion of the project. When you boss asks, "how are things coming?", you can reply, "72% of the tests pass." No more replying with vague answers and trying not to commit to anything. It is also a good "Light at the End of the Tunnel" for you as a developer. You can plan your days as, "I'm gonna get 10 tests to pass today." and you can feel good if you get 14 to pass, and know that if you work an extra hour to get all 10 tests to pass, then you accomplished your goal.


Design Ability

Writing your tests first forces you to look at your code from the front. It's easy, as a developer, to look at your code from behind the bar. You know your ingredients and you know how to put them together. Sometimes coming out from behind the bar allows you to see the situation from the consumer's perspective, whether those consumers are end-users or other developers. It forces you to view your code in the way it will be used, rather than how to get it to do something. This will inevitably improve your design.

Separated Concerns

Good layered, encapsulated, modular code is the goal of any architect (or at least it should be), and Test-Driven Development, in come cases, forces you to separate concerns in order to test them separately. As soon as you start to delve into TDD, you;ll start to see discussions about mocking and dependencies. If I want to test a method in isolation, I have to force dependant objects that I am not currently testing to give back suitable results. Mocking helps me do this, but it also helps me to understand the boundaries of the encapsulation of my classes. What should my class know about that class? What shouldn't it know? This will generally force to to make good design decisions. If you are finding it very hard to test something without mocking up 5 different objects, you may need to rethink your design.


These are just my thoughts. I am still really new to TDD and have a lot to learn. If you see things that I have forgotten from this list (undoubtedly a lot of things), or you think that some of my assumptions or assertions (pun intended) here are incorrect, leave me a comment.


Posted on Wednesday, April 30, 2008 1:17 AM | Back to top

Comments on this post: The Benefits of Test-Driven Development

# re: The Benefits of Test-Driven Development
Requesting Gravatar...
Great post, though I would point out with regards to your section on Accountability that following true TDD should always leave you with either n passing tests or n-1 passing tests where n is the total number of tests. With TDD you write a failing test and then make it pass (then refactor, then repeat), as opposed to an approach of writing all your tests first then making all of them pass. TDD is about an incremental approach, not writing all your tests up front. Appreciate that this post is well old now, hope you stuck with TDD!
Left by Chris Knight on Jun 15, 2010 3:41 PM

Your comment:
 (will show your gravatar)

Copyright © Lee Brandt | Powered by: