views:

203

answers:

7

I've spent a lot of time building out tests for my latest project, and I'm really not sure what the ROI was on the time spent.

I'm a one man operation, and I'm building web applications. I don't necessarily have to "prove" that my software works to anyone (except my users), and I'm worried that I spent a good deal of time needlessly rebugging test code in the past months.

My question is, while I like the idea of TDD for small to large software teams, how does it help a one man team build high quality code quickly?

Thanks

=> ran across this today, from the blog of joel spolsky, one of the founders of stackoverflow:

http://www.joelonsoftware.com/items/2009/09/23.html

"Zawinski didn’t do many unit tests. They “sound great in principle. Given a leisurely development pace, that’s certainly the way to go. But when you’re looking at, ‘We’ve got to go from zero to done in six weeks,’ well, I can’t do that unless I cut something out. And what I’m going to cut out is the stuff that’s not absolutely critical. And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that.”"

as i'm getting older i think i'm realizing more and more that it's just all about speed and functionality. i'd love to build unit tests. but since we only have so much time at our disposal, i'd rather build it faster, and rely on beta testing and good automated error reporting to weed out any problems as they crop up. if the project eventually gets big enough that this bites me in the a**, it will be generating enough revenue that i can justify a rebuild.

+5  A: 

I think that a situation like yours it helps greatly when you have to change/refactor/optimize something on which a lot of code depends... By using unit-testing you can quickly ensure that everything that worked before the change, still works afterwards :) In other words, it gives you confidence.

Joril
This is exactly it. When you have to refactor something 6 months from now you will know that you haven't introduced a ton of new bugs in the process. Even if you have to change the tests to account for new/changed functionality, it'll help you more fully understand the ramifications of your changes long after you have forgotten it all.
digitaljoel
Disagree. TDD is not QA activity it's a development activity. TDD drives application design. It's not about testing your code.
Vadim
@Vadim, is TDD to be used in place of traditional software design practices, or is it commonly used to augment it? understand that i'm an entrepreneur - if i can get a rapid prototype out in 2 months instead of three, i'd do it, and pay up on the technological debt later on.
Dave K
@David, Practicing TDD you're not going to deliver software faster. Actually it's going to take you longer to get product out of the door. Where you are going to save time and money it's on updates and enhancements. Only applications that fail don't need bug fixing and new features.
Vadim
@Vadim, this is what I thought - it's a long term investment. Vadim, my natural impulse is to build software "the right way", with a mind on the future. this is what drew me to TDD in the first place. but frankly, considering that success rates on any venture are not high, I think it's probably more responsible to build a prototype without building unit tests, with the plan to rebuild in phase 2 if the project generates sufficient interest. Thanks for your help!
Dave K
A: 

In theory team size should not matter. TDD is supposed to pay off because:

  • You test the code so you get the bugs out

  • When you maintain or refactor the code you know you didn't break it because you easily can test it

  • You produce better code because you focus on edge cases as you write the code

  • You produce better code because you can refactor the code with confidence

And generally I do find that the approach is valuable. I must admit to being in two minds about the ongoing maintenance of some tests.

djna
+5  A: 

TDD doesn't really have anything to do with team size. It has to do with creating the smallest amount of software needed with the right interface that works correctly.

The TDD process requires you to write only just enough code to satisfy a test, so you don't end up creating code you don't need.

Using TDD to design a class makes you think as a client of the class, so you end up creating a better interface more often than if you developed it without TDD.

TDD, by its nature will acheive 100% code coverage, proving your code works. A side-effect of this is that you and others can now more safely change your class because it has a full suite of automated tests.

I should add that its iterative nature creates a positive feedback loop as well, so as you iterate you gain more and more confidence in your code.

SingleShot
+5  A: 

TDD is not only about testing, it is also about designing your classes / API.

I mean: by writing a test first, you are forced to think on how you want to use your class. So, you first think about the interface of your class, how you want to use your class, and hence, your object model becomes more usable and readable.

Frederik Gheysels
The only correct answer here so far. See my reply to Joril answer.
Vadim
A: 

Even before the term TDD became popular, I've always written a little main function to test whatever piece I was working on. I'd throw it away right afterwards. I have trouble understanding the mentality of programmers who could write code that never been executed and plug it in. When you find a "Bug" after doing that a few times it can take days or even weeks to track down.

Unit testing is a slightly better way to go because your tests hang around and you can see the intent.

Unit testing will find the bug much faster than testing from a UI after integration--it'll just save you time.

Now saving all your unit tests and creating a suite can be of less value if you are single, especially if you like to refactor a lot (You can easily spend more time refactoring tests than code), but the tests are still worth while to create.

Plus, test-driven development is kinda fun to a degree.

Bill K
+2  A: 

rebugging is always needless - just don't delete the bugs in the first place...

For a real answer, you can't do better than 'it depends'. If:

  • you don't tend to have the kind of problems that automated unit testing can find (as opposed to performance, visual or aesthetic ones)
  • you have some other way of designing the code (e.g. UML)
  • you don't tend to have cause to change things while keeping them working

It could well be the case that TDD doesn't really work out for you.

Or maybe you are doing it wrong, and if you did it differently it would work better.

Or, just maybe, it is actually working but you don't realise it. One thing about working solo is that self-assessment is difficult.

In general, people's self-views hold only a tenuous to modest relationship with their actual behavior and performance. The correlation between self-ratings of skill and actual performance in many domains is moderate to meager—indeed, at times, other people's predictions of a person's outcomes prove more accurate than that person's self-predictions. In addition, people overrate themselves. On average, people say that they are "above average" in skill (a conclusion that defies statistical possibility), overestimate the likelihood that they will engage in desirable behaviors and achieve favorable outcomes, furnish overly optimistic estimates of when they will complete future projects, and reach judgments with too much confidence. Several psychological processes conspire to produce flawed self-assessments.

soru
Everyone's answer was good. personally, this one rung the most true to me. especially the piece where it's probably working and i just don't know it - this is what i was hoping, i just wanted to make sure i wasn't completely missing the point. to be honest, while i think TDD might force some people to build only the software that's needed, i think (and i could be wrong) that i don't necessarily write unneeded code, with or without it. in fact my basic question here is "are the TDD tests unneeded in my case?"
Dave K
if you properly think out and design your software and it's features ahead of time (as soru says, UML) i don't know that you'll be writing much unneeded code - and frankly most of the time you're going to waste a lot more time developing non-core features prematurely (high level mistakes) than unit-level mistakes that I think could be avoided by using TDD.
Dave K
A: 

I've found that people concentrate too much on the TEST in TDD. There are many who don't believe that this is what the originators had in mind.

I've found that BDD is quite useful, no matter what the problem size. It concentrates on the gathering of how the system is supposed to behave.

Some people take it all the way to the creation of automated unit tests. I use them as both specifications and test cases. Because they're in English, it is easy for the business to understand them, as well as the QA department.

In general, it is a formalized way of recording specs, so that code can be written. Isn't that what the ultimate goal is?

Here are a few links

Brad Bruce