Dhananjay Nene is a Consulting Software Programmer and Architect. Dhananjay is a DZone MVB and is not an employee of DZone and has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

Rinse and Repeat With TDD

  • submit to reddit

I must confess having had a awed love relationship with TDD (Test Driven Development). This is the style where you first write the test cases and then write the code to make them pass. I’ve always felt awed by it. I have always firmly believed that it is the right way to offer sustainable quality. As someone who hasn’t been particularly awed by separate QA teams, I have always imagined TDD to be the silver bullet to offer controlled, sustained, high quality. Well, the silver bullet is a bit of an exaggeration, but sounded nice while I was on a roll :) . A number of times I wrote automated test cases post facto. But when the rubber met the road – I didn’t ever implement TDD.

Its probably a function of style. I like to write a piece of code and then keep on testing it against different scenarios and often keep on remoulding it substantially. My focus is at this stage on the code structure – the design aspects. Trying to do it with TDD always created a mess. The amount of intense refactoring I do always meant I soon got tired of also simultaneously refactoring the test cases and gave up on them soon.

Anyways, I finally think I found a formula that works – at least for me. I do not write production code in the first pass. I just write prototype code. I keep on playing with it, shaping it, challenging it, cajoling it, recasting it. Until I’m satisfied with the overall structure and internal design. Now when thats done, I rewrite it. Completely. Umm, I copy/paste maybe 40-50% of the code. But this time I write it on a completely new fresh set of files. And I write the test cases before I write the code. I find I can now really write tons of test cases and code quite rapidly. And with the tremendous satisfaction that at the end of the day, I now have the control harness to be able to keep on adding new features without having to continuously worry if I broke something else. With substantially detailed test cases, now I can actually feel quite confident that if I did break something – I’ll get to know it. Not next month, not next week, not even tomorrow – in the next few minutes.

So this approach seems to be working for me – the initial efforts have delivered great results and I’m quite satisfied. Now just wondering what to call it – for lack of a better term I shall term it “Rinse and Repeat with TDD”.

So if TDD works for you – great. You have one of the most important coding disciplines nailed down. But if you’re wanting to try to do TDD but haven’t been able to successfully implement it – you may just want to check out the Rinse and Repeat with TDD style. Who knows, you might find it useful too

From http://blog.dhananjaynene.com

Published at DZone with permission of Dhananjay Nene, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Andrew Arrigoni replied on Wed, 2009/12/02 - 7:17am

This is a lot closer to what I do. I usually end up writing a few tests, writing a bit of code, realizing new tests I need to add, refactoring a whole bunch, realizing some MORE tests I need, refactoring a whole bunch, etc.

Maybe it would be cleaner for me to write a working prototype first. Hopefully by then I'll have come up with most of the tests I need to write. :)

Philopator Ptolemy replied on Wed, 2009/12/02 - 8:59am

IMHO, this is a lot more realistic way to approach TDD. I do something very similar - coarse prototype that satisfies basic requirements - it is much easier to develop it straight without TDD. Then, when i get a grip on the problem and the outline of the solution - i can clean and bullet proof it with tests.

Probably TDD purists would argue that starting with tests would create different (and better) structure of the code than my prototype, but i find that a road to decent implementation is a lot shorter with regular prototyping. When combined with decent tests - the results seem to be good.

Benoit Guerout replied on Wed, 2009/12/02 - 10:59am in response to: Philopator Ptolemy

Indeed, during a spike it's sometimes very hard to have a pure-TDD approach.

For example when I'm not confident how to deal with a framework, i always create a spike project to learn and play with this framework.

 In this project, TDD rules are not always applied.

 When things come clear i go back to my real-project and test / implement the new functionality...

Endre Varga replied on Thu, 2009/12/03 - 6:18am

The problem is that pure TDD makes a "mini-waterfall" design, that in my experience do not work even on small pieces. Maybe we should "agilize" TDD ;)

Mladen Girazovski replied on Fri, 2009/12/04 - 7:33am

For example when I'm not confident how to deal with a framework, i always create a spike project to learn and play with this framework.

 You should try the so called "learning tests" ;)

 About the Article, i think the problem is that TDD changes the way we work so radically, that people with lot of expirience in the old way have a hard time adjusting, the prototype approach can work, but the structure would be better if TDD was used, "interface discovery" is one benefit TDD has.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.