How does Test Driven Design help a one man software project?

Question

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.

Answer 1

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

• What's in a Story
• Introducing BDD
• Designing Klingon Warships Using Behaviour Driven Development

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.