I have been reading quite a bit recently about TDD and such and I'm not quite sold on it just yet.. I make a lot of small hobby projects(just me) and I'm concerned if trying to do TDD is overkill for such a thing. Though I have seen small open source projects with like 3 developers that do TDD. (though I have seen a few one-person projects that also do TDD)
So is TDD always a good thing to do or at what threshold does it make sense to use?
Small Projects can have a habit of turning into big projects without you realizing, then you wish you'd started with TDD :)
TDD shines in small projects. It's often much easier to adhere to TDD in a small project, and it's a great time to practice and get the discipline required to follow TDD.
In my experience larger projects tend to be the ones that abandon TDD at some threshold. (I'm not suggesting this is a good thing).
I think larger projects tend to abandon it for a couple of reasons:
From my personal experience I can say the following:
Everything has a cost-benefit curve.
Ignoring many of the oft' disputed benefits of TDD, TDD is worth it if your implementation will change sufficiently often that the benefit of having an automated test suite outweighs whatever extra cost might be involved in initial development.
I always find a question like this funny. What is the alternative? Writing code that you only compile and never run to verify its correctness? Do you wait until you deploy to production to find out if your class works at all?
If we never had a practice called TDD, or before JUnit was invented back in 1997, was there no code testing? Of course there was. So why is it such a big deal now that you have testing frameworks to help you with this?
Even a small project on a tight deadline won't want to wait until production to find out if it works. Write the tests.
It's not necessary for any project that's "small", but I define "small" as less than one class.
Overkill? Not at all. In addition to the main benefit, which is writing code you can rely on because you've thought about ways it can break, you'll be more disciplined and potentially more productive with test driven development. Pick up any of the Pragmatic Programmer books for tips and inspiration.
I would take the opportunity of using TDD with a small project just to get your feet wet. It would be a good learning experience even if you realize it's not for you.
Something I've heard from one member of our local Agile group is that she doesn't find TDD useful for the very earliest stages of the project, where you're essentially making quick sketches and you're not really sure what shape the thing is taking yet. But as soon as you have some ideas of what the interfaces look like, you can start using tests to help you define them.
TDD is another tool, like documentation, to improve the clarity of the code. This is critical when other people need to work with your code, but many of us find it's also very helpful when looking back at our own code. Ever had a hobby project you picked back up after being away from it for a while, came across a weird bit of code, and wondered "why the heck did I write that?"
I and others use TDD on any project that is more than say a few lines of code.
Once you get the testing bug, it's hard not to use TDD for anything. Personally I've found my code has improved several times over due to TDD.
I believe it's worth it for most any project. TDD and the consequent regression testing enables you not only to determine if components work as you write them, but as you introduce changes and refactorings. Provided your tests are sufficiently complete, you can cover scenarios for infrequent/unlikely edge cases and produce/maintain more reliable code.
Going forwards through the project lifecycle, the continuous testing cycles will save you the manual repetition of tests, and negate the obvious chance of repeating these incorrectly/incompletely.
Well, it is not really the amount of people that is the deciding factor for TDD (at least this is what your question kind of infers), but much rather the size of the project.
Advantages of TDD are, that all the code you are developing will pretty much be unit-tested. That way you save a lot of hassle when refactoring later. Of course this is really just necessary when your project has a decent size.
When you think that consequential errors that you don't expect might happen as a result of your writing code, TDD makes sense.
I'd say it totally depends on the given time frame. If you've got the time to spend almost twice the time you'd usually require, then go for it. But in my opinion speed is these days one of the most important factors (for competitive companies).
A project developed with good OO code is inherently well-suited for testing, and arguably can acquire a test-driven focus later in the development style. I'd actually say that when you're waterfalling on emerging technologies with a limited budget, considering all that is TDD is completely optional.
I think TDD is worth it no matter the size (EVEN if it's one class - since writing the tests first can help you come up with a more sane design).
The place that I feel it may not be necessary is when you are building a project in which you aren't sure what you want, and you are unlikely to care about maintainability. I find that there aren't ANY projects that fit that category at work, but I have found that occasionally I am developing personal projects in which this is the case. In these cases, I am usually learning a new framework and have no idea what i'm doing from the beginning, so my tests would be more likely to break over time for the wrong reasons, thus decreasing their value.
However, I am also acknowledging that not using TDD is costing me maintainability - once I know what i'm doing, I promptly fall back to red/green/refactor.
You have a lot of answers above. Your question is years-old, but allow me to chime in: Yes—do TDD! Test your code! Be smart about it.
TDD and BDD are best understood in the context of Hoare-logic preconditions and post-conditions (as well as other forms of code-correctness Boolean assertions). The best application of it I have ever used is Eiffel in EiffelStudio.
The Code-Fail-Correct model is okay until one starts to measure how much time developers and QA people spend on correcting bugs.
You can also go hugely wrong with TDD and BDD as well. TDD can end up generating massive code-bloat, where your test code is larger and harder to maintain than your production code. BDD—which is really mostly DbC—can be misunderstood, misapplied, and mismanaged with its own complexities, bloat, and cost-overhead as well.
The deepest need is for a language specification, compiler, IDE, and testing system where TDD + BDD (aka DbC) is baked in, with all the proper parts in their proper place instead of bolt-on Frankenstein nonsense trying to masquerade as TDD + BDD.
I find it humorous to watch programmers twisting in the wind of trying to shoehorn common implementations of TDD and BDD into mainstream languages that have no sense of Design-by-Contract at all. Everyone interprets TDD + BDD through this language-spec/compiler/IDE lens as though they truly "get" what it is. They never actually see just how silly and distorted it is.
TDD + BDD (DbC) get distorted just like other technologies and topics. For example: Do not attempt to use Java as a lens for understand Object Oriented Theory. The same is true for C++ or other C-derived languages. Trying to use a language as a means to learn OO is like thinking that knowing your calculator is going to cause you to understand calculus.
The only language specification, compiler, IDE, and testing system I am aware of that is built from a theory understanding of TDD and BDD is Eiffel and EiffelStudio. I have been using it for some 20 years. I've been around this block many times. It frustrates me to see you all suffering and twisting about on subjects that (to me) are as clear as a cloudless summer day in springtime.
