Hello, 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?
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:
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.
When you think that consequential errors that you don't expect might happen as a result of your writing code, TDD makes sense.
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.
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.
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.
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 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.
Small Projects can have a habit of turning into big projects without you realizing, then you wish you'd started with TDD :)
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).
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.
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?"
From my personal experience I can say the following: