I\'m the only developer in my (very small) company and I\'m about to start on a medium sized ASP.NET web application for said company.
I\'m trying to figure out if
Caleb - I wanted to pitch a site that has been constructed to aid learning TDD by yourself at home. You learn better if you are not under pressure. Just google for "tdd-problems" and you will find it.
Note that TDD is not about testing; it is a development process. The testing is not done to replace the testing function - it is what defines the dev process.
It sounds like you are talking about unit testing and other automated testing. Testing is good. Automated testing is good. Don't be afraid to make mistakes. If you think about your code and how to automate testing as much as possible then you are in a good position - however there is a cutoff of diminishing returns. 100% automated testing is probably not something that is cost-effective - especially for an organization that you describe.
If you are really talking about TDD (What the experts would call TDD), that can also be good. There are many development processes. It is good to remember that development processes are frameworks and guides - not a religion to be followed like a quest. No process is one-size fits all. Do what makes sense for you and improve as you go. Having just one person in a dev organization makes changing process fairly painless. Address your high-risk issues first and put some lightweight process in place for those before going after low-value issues.
Do you have components that are easily unit-testable? Can you construct your app to be a set of unit-testable components? That's really the mindset to think in when working in a TDD environment.
Its easy to say "its a GUI app! its impossible to unittest my stuff"! This can be a self-fulfilling prophecy. Certainly you can't easily unittest the layout of all your widgets, but how much of your program is tied to how your widgets are layed out? You may stop yourself from doing good TDD because some aspect is too tightly coupled to the layout of your GUI widgets, or its too tightly coupled to something else not easily unittestable. Stop and challenge yourself-- is this really the case? Can I compartmentalize and modularize my code such that it can be better isolated from these parts of the system? Is it appropriate to do so (do the unittesting gains merit the cost?). Don't accept carte blanche that its impossible just because your software is tied to non-unittestable components.
Only one developer is actually a fairly small sized development effort. Even if you expect a lot of screens, it still takes a long time to for a single coder to get into something medium (unless they've gone nuts with cutting and pasting).
I'm not a big fan of TDD, but if you are relatively new programmer (less than 10 years) you're by yourself and you're worried about quality issues, I'm sure it will both slow you down, but also help you improve your work. For younger programmers it forces them to focus more intently on the real underlying behavior of the code and get it working one step at a time (one early common mistake is too pound in massive amounts of code, and then try to debug it all at once. Old coders can get away with it, young ones usually need to work on smaller pieces at a time). Fans often say it majorly changed the way they code (usually making the overall work easier). At very least you could start with it, and ditch it later if it isn't really helping.
Your biggest problem, for which TDD won't help, is getting a good architectural structure for the web app. One that you won't want to throw away in five months. Web apps can be very tricky, few people get it right in the first ten or twelve times.
The best way to learn is by doing. If you've read that much on it, it's time to dive in - and as a single developer, having unit tests can be a godsend, since there's not another pair of eyes to look over your code.
I'm still a new developer and stepped into a company where the application development was already ongoing. TDD helps me ensure that new changes don't break what has been done already and as I work along it helps from having to do massive amoounts of bug hunting when I add or modify code.
I have loved everything I have learned from it and strongly recommend taking the time to learn TDD.
-my .02