Meaningless Drivel is fun!*
The moose likes Blog around the Campfire and the fly likes why TDD is Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Other » Blog around the Campfire
Bookmark "why TDD is "harder"" Watch "why TDD is "harder"" New topic
Author

why TDD is "harder"

Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30929
    
158

A hypothesis on why TDD seems "harder" especially at first. Thoughts?


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

For me its often time constraints. They want a champagne wedding on a beer budget and they want it yesterday. On top of that your standing on the carpet of shifting requirements, everything is in a constant state of flux. Write it, change it, move it, delete it, refactor it etc. Writing the unit tests is just one more thing to write and re-write. On projects like these TDD on all but the most important stuff falls by the wayside for me. Once things stabilize if time and money permits I always go back and add them but that is not TDD. Of course often times the process of adding them calls out some opportunity for refactoring as well.


[How To Ask Questions][Read before you PM me]
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30929
    
158

Bill Gorder wrote:For me its often time constraints. They want a champagne wedding on a beer budget and they want it yesterday. On top of that your standing on the carpet of shifting requirements, everything is in a constant state of flux. Write it, change it, move it, delete it, refactor it etc. Writing the unit tests is just one more thing to write and re-write.

Perhaps the unit tests are too low level? If written at an interface level, they can provide regression and actually speed things up. (once you achieve fluency in testing.)

We had a production problem at work once, the same day as robotics kickoff (where they announce the challenge for teams). My contribution was to write a converter to reverse the bad data. It was in my interest to get it done as fast as humanly possible so I could go and brainstorm with the team. And of course it had to be perfect so I didn't get called to go back to the office. I didn't have time to NOT do TDD there. And yes, my code was perfect. It wouldn't have been without the tests though.
Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

Unit tests usually are at the interface level, assuming its not a utility class. Sometimes testing the functionality in and out of that is fairly simple. Some implementations tie together or integrate several other service layer interfaces which all must be mocked, and of course all the conditionals, and edges must be appropriately tested. That takes time especially if tomorrow everything changes and you are doing something totally different and all that code and its tests get thrown away. Some of the development I do is very rapid and the requirements can literally change on a moments notice. Sometimes you just have to pick where the tests are most important or not test all the branches, or deadlines slip. I am pretty quick with JUnit, and Mockito. By the time code is productionalized the unit tests are in place, but we are talking about TDD here.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30929
    
158

Bill Gorder wrote: Some of the development I do is very rapid and the requirements can literally change on a moments notice.

Yet it is worth writing the code? .

I can't tell if this is a spike or if it isn't known in advance what is throw away.
Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1680
    
    7

if it isn't known in advance what is throw away.


Yes that
 
 
subject: why TDD is "harder"