The Great Benefit of Test Driven Development Nobody Talks About

The feeling of productivity because you are writing lots of code.

Think about that for a moment. Ask any developer who wants to develop why they became a developer. One of the first things that comes up is “I enjoy writing code”. This is one of the things that I personally enjoy doing. Writing code, any code especially when its solving my current problem makes me feel productive. It makes me feel like I’m getting somewhere. Its empowering.

Python IDLE Screenshot

I love writing unit tests and watching them run.

Now think about how test driven development fits into this. You write a test, you write a method to pass the test. You write another test, you modify the method. You write another test, you modify the method. Lather rinse repeat. After you have met all your requirements you have quite a bit of code.

Now why is this important? Well firstly you feel like you have done a lot because you have a lot of code. Secondly it plugs straight into the part of the brain that likes rewards. Its the same way that any game becomes addictive. You begin with a specific goal. To reach it you take small steps and each one rewards you as you get there. When you finally make the last hurdle you can look at each of the steps you took, and you feel a great deal of accomplishment.

The above for me is what keeps me turning back to TDD. I love the feeling of success each time I run the tests and everything comes back fine. I love being able to finish off a method knowing its as good as I can make it. Finally I love having a lot of code which while the user will never see it at least makes me feel like I’m getting somewhere.

16 thoughts on “The Great Benefit of Test Driven Development Nobody Talks About

  1. Agreed. I do love writing code and especially the feeling of knowing that I wrote quality code when I see it pass a series of tests. Occasionally, I skip the test writing part out of trying to meet a deadline and I usually feel a void knowing I should’ve written the test code and also the uncertainty of not know whether the code will work exactly as I intended.

    • Nice to hear Rob. I have the same experience. Every project I write tests for I feel way more confident on and I am more motivated to make changes and improve. I find it just plugs into some sort of addictive part of my brain which pushes me along more and more.

  2. “When you finally make the last hurdle you can look at each of the steps you took, and you feel a great deal of accomplishment.”

    So true!

  3. All good stuff, I am totally into unit testing at every level possible also. But remember you should always write as little code as possible – i especially mean the code that is being tested. Rather than re-inventing the wheel use frameworks that have already solved the problem (and which usually come with their own test suites)

    You could also apply this to your test code – e.g. use easymock, mockito instead of rolling your own mocking framework etc etc. The best code you can write is no code. The books ‘Getting Real’ and ‘Rework’ by 37 signals (The Ruby on Rails guys) is well worth a read in this respect.

    • Agree. The thing I have found with TDD is that if you are doing it right you end up with less code all around anyway. You only get the tests that you require and you only get the method doing exactly what it requires. A win all round.

  4. Is this article a kind of ironic?

    For me it feels always wrong to write 100 lines of code for something that could be done in 10 lines. You sit in front of your computer the whole day, fully in flow, write code like crazy, use all kinds of test tricks like mock ups and dependency injection and in the end you implement a functionality that could be written in 1 hour by a programming beginner in 10 line lines. Yeah, Great!

    In a long running project with several developers there is now way around TDD but praising the number of lines of code you have to write as an benefit sounds sick.

    • I think you have misinterpreted what I wrote, which is my fault for not being clearer. If you are doing TDD correctly you find you end up writing less code. Now this applies to the method itself. With the tests in addition you end up with more, but usually not as much as you would think, and the feeling of accomplishment that you have a end to end tested application with progress showing how you got there is worth a lot.

      I think the way I think of it is yes I could write a method to do something in 10 lines and ditch the tests. However with the tests when the time comes to improve the performance of that method im golden because I can change anything without fear of introducing bugs to my tested functionality. This is a big win when it comes to maintenance.

      Don’t get me wrong, writing a million tests which prove nothing is useless, but proper TDD really can give you a sense of getting somewhere.

      • So your real point is: With tests you can improve the code later without breaking it? That’s not new.
        And if you write with TDD less production code then without TDD that means either that:

        1. You are just writing unnecessary or to complicated code without TDD.
        or
        2. You forget to write some tests.

        The second one can easily happen. With TDD I also have often the sense of getting somewhere. This kind of proud when all tests pass. But realistically that means nothing. All your tests can pass but the application still sucks. Considering a limited amount of time and mental resources I think tests can sometimes really distracts from the real problems and the proud about passing tests is similar to the simulated success-feeling that a drug gives you.

        Even the production code can get easily bigger by TDD because you have to add the hooks for easy testing like interfaces or dependency injection that were otherwise not needed.

        No doubt: TDD is just needed in many projects. It reduces the risk of breaking existing code and the need for manual testing (which really sucks up time and energy).

        But don’t fool yourself to think that just because you write a lot of test code, your application or your software design rocks.

        • No thats not my real point, thats the point of TDD in general along with better more modular code.

          I think you are underestimating the feeling of success that comes with this. Thats fine, maybe it doesn’t work for you. I just find that in my personal experience that if I keep getting rewarded with passing tests I am more encouraged to keep going with the tests and feel more accomplishment at the end.

          To me that feeling is worth a lot, because there is nothing worse the writing a a complex method only to feel relief that its over and then dread touching again based on your last experience.

  5. I like the spirit of your article, especially the portion of where you get a good feeling of doing quality code. However, I agree with some of the other responders. I don’t more feeling of accomplishment when I write less code. So if I write a piece of code with TDD, then I refactor mercilessly, I may have started with 25 lines of code, and then I whittled it down to 10. This is where satisfaction comes in. this also applies to refactoring test code, where you reuse setup methods, use mocks, and treat test code to be as clean as any other portion.

    great article.

    • There is no reason you cant combine the two. Thats the point of TDD. You have your tests, so re-factor your method to make it as small as possible. But while you are writing the method, I find the buzz of having each test pass really motivates me. Especially when the method is finished, I can look back at my milestones (the tests themselves) and my finished product (the method).

      Glad to hear you liked the article though!

    • To be honest, 6 months ago I wasn’t sold on it either. I then decided I would apply it on a smaller subproject I had and found the experience so rewarding I want to TDD everything. I really think its something every developer should at least try before dismissing.

  6. Nice post on TDD, I feel mostly the same this this appoach.

    TDD helps me to be confident in my job, I like to feel confidence. More overover there are a lot of benifits come with TDD, as simple design, clear code, simplified refactoring etc.. Unfortunatelly not a lof of people really understands it.

    • Thanks Alexander. I totally agree. All of the benefits of TDD really allow you to be more agile and creative when it comes to your solutions. I am also in the process of trying to convince people at work of this, but some people are slow to change.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>