Why my attempt to apply tdd failed?


Intent of my Blog

The intent of this blog is to write down the reasons for my failure to apply test driven development in my current project. Uncle Bob Martin in his interview on infoq said that “Developer is not professional if he does not practice test driven development”. We tried following tdd but failed (are we not professionals😦 )!!

Brief Background

We had a major release few months back and till that time we were not following Test Driven Development so when the talks for the subsequent releases started we thought that we should follow tdd.I was given the responsibility to come up with strategy on how we will be applying tdd in our project. So i started with reading kent beck book Test Driven Development: By Example. I also read lots of articles  on infoq and testdriven.com to get a good and thorough understanding of tdd and was convinced that we should apply “TDD”.I gave a presentation-cum-coding demo to my team and after my demo we all were convinced that we will be applying TDD.

Ist Iteration using TDD :-Whenever you start some new thing you are excited, the same was the case with us.So before writing any class or any piece of code we used to write a test for the same. We were developing our code in an incremental manner, letting the design evolve as tdd gurus says and we were seeing small benefits like fixing programming errors like NullPointerException were caught in the early stages before the code goes to the QA team for testing.
For the next two weeks i was on leave and when i came Iteration 2 had started and tdd was no where…. So what went wrong………………

I asked my team why now we are not using tdd and the answer was that client changed the contract of one the web service that we published in iteration 1 although we had taken the feedback from him on the previous contract but somehow later he felt that this was not correct and we have to re-implement the web service with new contract and because of pressure of time we commented out all the tests and wrote the code without tests.

I started thinking about our failure to apply tdd because i think time pressure is not the only reason why teams fail to apply tdd there are many reasons. So i am writing down some reasons(in no particular order) which i think led to us not apply tdd:-

  1. Time:- Developers think that writing test cases before writing code requires more time and most often under pressure circumstances time is more important than writing test cases.
  2. Boring to write test cases first:– Its very difficult to get into the habit of writing test first than code so developers are reluctant to write test first.
  3. Client Support:- When we told our client that we will be applying tdd in our code, the response was that tdd doesn’t provide better results and in a longer run developers don’t maintain the test and they become irrelevant after some iteration.Client cares about money not test cases.
  4. Writing Exhaustive test cases :- I think tdd will make sense when you are able to cover most of the scenarios in your test class. More often what happens is that developers just write the basic test and test class doesnt evolve to incorporate all the test cases as a result developer thinks that when the number of bugs getting raised is not decreasing why should i write test.
  5. Patience :- I think it is very important that we should not expect everything to go fine and everyone to become tdd guru in one iteration. So we should give tdd few iterations before we can judge whether its useful or not.
  6. Poor Examples :- The example with which tdd is often taught are very simple as compared to the one you face in real life scenarios.So it becomes difficult to follow tdd when there is some real complex problem come.
  7. Legacy Code

In short, i can say that applying tdd requires a complete change in mindset you have start fresh.These are some of the reasons that i could think of at this point of time why applying tdd failed.
Please share your views also.

17 thoughts on “Why my attempt to apply tdd failed?

  1. Urs Enzler

    Hi

    What you describe is actually quite normal for a team that starts using TDD.
    My team started doing TDD about 2 years ago and we faced mor or less the same problems as you describe them in your post.
    However, it was worth the effort. The reason is simple (and it’s the only reason that counts for our customer): when looking at the whole cost of a feature (analysis, development & testing, maintenance), it decreased dramatically. Meaning the we develop software today at lower costs.

    Therefore, I recommend to you that you stick to TDD. But get help from someone who is a TDD pro. Otherwise, the time to acquire TDD skills takes very long or even worse when doing TDD the wring way, will lead you a way with slow development, a lot of unmaintainable unit tests and nothing done on time and quality.

    We spent a lot of time on reflecting how to improve our TDD usage. That gave us a common vision and a good team learning curve.

    All the best
    Urs

    Reply
  2. Franco

    You are professionnals. You try things, fail sometimes and then learn from your mistakes to improve ;o)

    It is true that (most)customers don’t care if you TDD or not. They want results and this is why it is difficult to adopt new practices in projects that have already a lot of pressure. Ideally, you should include in your estimation the learning curve for a new technique, even if this is not easy in a competitive environment.

    Good luck,

    Franco

    Reply
  3. Jose Noheda

    It’s a matter of motivation really. In my personal (OSS) projects I write tests and use quality assurance tools like Sonar just because that code belongs to me. At work I have to admit that I’ve been unable to convince me and other developers of the benefits of TDD. After all, if it fails someone will fix it in the future. Developers have to eat as well😉

    Reply
    1. whyjava Post author

      In my personal work i too try to follow tdd but in my case i think the difficult part was getting the whole team think the same about tdd.Developers try to find out new ways not to write test.

      Reply
    1. whyjava Post author

      Thanks for sharing your insight.I think the biggest problem is keeping the whole team on same page.If you are the only one in your team trying to force tdd it does not work.And making sure everyone understand the true benefit of tdd is difficult.

      Reply
  4. cease

    you gave up too early. The benefits of TDD aren’t really realized, till you get to a stage in your project, where complexity increases, and you need to do some big refactoring, or major features. With TDD , you can know right away, what’s gonna break or even if the code you write will work. I guess initially, I can tell you with a high level of certainty that my code will be bug free based on my tests. Even if you can’t maintain 100% test coverage, you need to have tests, for major pieces of your work.

    Reply
    1. whyjava Post author

      Actually i am still trying to write test cases but i am now focusing on integration tests not unit test.
      I think in our project writing integration test makes more sense.

      Reply
  5. Mark Menard

    Getting into TDD is hard. It sounds to me like you were also dealing with a legacy code base on this project? Is that right? Also what platform are you using? Test framework?

    Reply
    1. whyjava Post author

      let me explain you our project state, we have been doing development for last one year on this product for a particular customer and we were not following tdd.We had a release to that customer now we are working for a different customer and we will be extending the product we build(means we will be using the same code which does not have any test).For new customer we decided that we will be following tdd.
      We are working on java platform and used junit 4 as test framework.

      Reply
      1. Mark Menard

        I thought that might be the case. Introducing TDD into a large source code base that doesn’t have tests can be very challenging. Code that wasn’t written to be tested usually requires a lot of refactoring to make it testable.

        I would recommend that your team or someone in your company try TDD on a greenfield project first. That would allow to you to work the implementation code as well as the test code together.

        In addition to JUnit what are you using to setup test scenarios? Are you using integration tests with database data? Is this a web app? Are you using a mocking framework?

        Mark

      2. whyjava Post author

        Yes you are correct that applying tdd in an existing large project is very difficult as it require hell lot of refactoring.
        Yes we wrote integration test for our code.In my view, integration test make more sense in our case and i am currently working on that as well(unofficially).
        Our app is not web application we have a set of spring based soap web services and some other application consumes it.I didn’t get what you mean by “In addition to JUnit what are you using to setup test scenarios?”

        Thanks

  6. Fareesa

    Greetings!
    Hope you are doing well, I need some research input for a study based on Offshore Agile software development.

    It would be very kind of you if I may be able to get your participations for this research study

    The research form could be access at

    http://spreadsheets.google.com/viewform?hl=en&formkey=dEQ1WEswNllmdjZjY0tlbDRPcW5yc0E6MA..

    Your feedback will help me to conclude, which type of the software development is best suitable for offshore and Agile process model, and what kind of developmental strategies a company should adopt in a particular situation, or for a specific project type, for successful development of the offshore software project by using Agile process model.

    I will appreciate your contribution and support.

    Thank you

    Regards
    Fareesa Malik

    Reply
  7. Pingback: Interim build to testing team worked for us « My Thoughts on software development

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s