Conventional TDD is Sin!!
Conventional TDD is Sin!!
Join the DZone community and get the full member experience.Join For Free
10 Road Signs to watch out for in your Agile journey. Download the whitepaper. Brought to you in partnership with Jile.
TDD is sin… oops!! conventional TDD is sin(sounds much better than the previous statement :). I completely agree that TDD is the way to write a high quality software and statistics has proven this fact. Let me put down that statistical data,
Advantages of TDD:
• 87.5% of developers reported better requirements understanding.
• 95.8% of developers reported reduced debugging efforts.
• 78% of developers reported TDD improved overall productivity.
• 50% of developers found that it decreased overall development time.
• 92% of developers felt that TDD yielded high-quality code.
• 79% of developers believed TDD promoted simpler design.
The aggregate score of these findings shows that 80% of developers found TDD to be effective. Also, there was an increase in code quality which passed 18% more functional black-box tests.
Challenges of TDD:
• 40% of developers found adoption of TDD was difficult.
• 16% increase in development time of projects.
These results were of a survey done, and not scientific facts. It proved difficult to find statistics on TDD due to the "new" nature and adoption of TDD in the IT arena, which is why our results were based on surveys that were found across the internet. I’m not going to talk about the advantages of TDD. Lets go and take a look into the challenges section from the above statistics.
1. 40% of developers found adoption of TDD was difficult.
I definitely belong to that 40%. Let me make it clear again, I'm not against TDD its just that I find it difficult to follow it because of blah, blah... (some excuses-and I don't wont to disclose them).
2. 16% increase in development time of projects.
This part is totally ridiculous. I personally cannot digest this. Maybe I can add this as one reason why I belong to that 40% of developers:)
And please keep in mind, this 16% is just a average. This number is going to be proportional to the complexity of your project and boundaries of your testing.
Lets jump a little deep into this 16% part. In real world scenerio, what factors affects the time to write unit tests,
1.Mock some of the methods or services to avoid database hits or network connections.
2.Test your code with different data sets.
3.Halfway through the project the requirement change-->architecture change-->code change-->change the unit tests supporting them.
Again in real world, people spend so much time in the below step ,
"Writing unit tests for the same block of code but with different data".
To me, this could constitute 50-75% of that 16% factor. Lets take a sample look at typical development process,
The team spends significant time deciding the technology stack
The team spends significant time to design the architecture of the source code
What’s the next step?
"Hello Team-- use this technology stack and implement the code using this architecture. And, also write unit tests for your code."
"Also" – that’s were the actual problem is. If TDD is so important why didn't we spend enough time to decide how we have to implement TDD. If we spend some time during the design phase for this, I'm sure the two challenges listed above can be addressed to great extent.
Fine, enough said about the challenges and problems . Lets move to the next part,
How do we address those challenges???
Lets take a quick look at some of the popular acceptance testing frameworks like FIT or Concordion. The immediate response, "its so easy to write and maintain them!!!".
1. Its so easy to write a test scenario
2.Easy to understand and modify the test scenario. Even QA or customers can write the acceptance tests.
Now comes the next question,
1.why cant my unit tests have the same features as a acceptance testing framework??
The first thing I did was, try to integrate FIT into my JUnit. I realized in a hard way, that FIT is not designed to work as a unit testing framework. It can never replace unit testing framework .
So,why cant we apply the same strategy used by FIT in our unit testing framework? What makes it so easy?
1. Test data and expected behavior should be separated from your test code.
2. Make the test data easy to understand .Writing test data for your test code should not require java skills.
Thats it. Two simple constraints. If our unit test address these two issues, the unit tests will get all the power and features of a acceptance testing framework.
I did some research analysis various frameworks to separate test data from code. Few of them that caught my attention were,
1.Xlsbeans from amateurs
3.Datapool from eclipse TPTP
In the next article I will put down a comparison chart between these 3 frameworks. I preferred Xlsbeans to get this job done.
Published at DZone with permission of Ramsundar Kuppusamy , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.