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:-
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Shekhar Gulati 
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
Hi,
Nice post. We also faced the same issues while applying tdd in our project.
Thanks
Shekhar
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
Most customers don’t care about your programming language or indentation style (ok maybe they do) but you still have to make the choice, not them.
A quick cost/benefit analysis for test driven development can be broken down into:
1. Does writing tests with code (not necessarily before!) decrease defects or increase productivity while writing code (short term).
2. Does having tests exercising code (you have to run them!) decrease defects introduced or increase productivity while modifying code (long term).
You need to consider both of these, and while it takes a shift in the way most developers think to plan out their tests while writing the code, and there could be waste if you throw away that code, the benefits become more apparent as the code base grows, interdependencies develop, and refactoring is needed.
However, most people have trouble writing tests that are decoupled from the implementation. In this case, tests can end up slowing down development because you can spend as much time refactoring tests as application code.
A good rule here is that if the code changes but the behavior doesn’t it shouldn’t break the test. So you should only be testing things that are independent of implementation.
Now, it’s ok to write tests in development to explore, and it’s ok to throw away those tests when they’re not needed anymore or requirements change. A unit test should look like a debug print statement and be about as complex. The beauty here is that it’s saved for you to use later.
I think you are right, the Examples in the web are very simple most times. In the wild it is much more complicated.
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 😉
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.
There is a saying which states that you need to write 1500 tests to become good at TDD… 🙂
I have analyzed your points here:
http://giorgiosironi.blogspot.com/2009/09/failed-attempt-to-apply-tdd-response.html
Hope to give you some feedback 🙂
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.
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.
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.
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?
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.
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
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
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