Should I start using TDD on a project that doesn't use it already

Question

I have a project that I have been working on for a while, just one of those little pet projects that I would like to one day release to open source.

Now I started the project about 12 months ago but I was only working on it lightly, I have just started to concentrate a lot more of my time on it(almost every night).

Because it is a framework like application I sometimes struggle with a sense of direction due to the fact I don't have anything driving my design decisions and I sometimes end up making features that are hard to use or even find. I have been reading about how to do TDD and thought maybe this will help me with some of the problems that I am having.

So the question is do you think it's a good idea to start using TDD on a project that doesn't already use it.

EDIT: I have just added a bit to clarify what I mean by struggle with a "sense of direction", it properly wasn't the best thing to say without clarification.

Answer 1

In my opinion, it's never too late to adopt a better practice - or to drop a worse one - so I'd say "Yes, you should start".

However ... (there's always a "but") ...

... one of the biggest gains of TDD is that it impacts on your design, encouraging you to keep reponsibilties separate, interactions clean and so on.

At this point in your project, you may find it difficult to get tests written for some aspects of your framework. Don't give up though, even if you can't test some areas, your quality will be the better for the areas you can test, and your skills will improve for the experience.

Answer 2

Yes.

Basically, you can't do any harm by adding TDD for any new code you write, and any changes you make to existing code. Obviously it would be tricky to go back and retro-fit accurate tests to existing code, but it certainly couldn't hurt to cover the primary use-cases.

Maybe consider having a look at Brownfield Application Development in .NET? It is full of pragmatic and practical advice for exactly this scenario (one of the definitions offered for "Brownfield" is "without proper unit tests").

Answer 3

At worse, you can just do TDD on new stuff, while you slowly create tests for your existing code base.

Answer 4

Yes, absolutely a good idea to start doing TDD.

You will pay a start-up cost for at least two reasons:

1. Learning a new skill TDD/unit testing.
2. Retrofitting your code to be testable.

You'll need to do some of both, but as you work if you find yourself struggling think of which of those two is the source of the effort.

But the end result is worth it. From what you describe this is a project you intend to live with for quite a while. Remember that when you lose an hour here or there. In a year you'll be very happy that you made this investment both in your skill set and the code base.

Answer 5

As others have said, TDD shouldn't hurt a project in progress, but think carefully if you're tempted to do large-scale refactoring just to allow testing. Make sure the benefits justify the cost.

I'm a little concerned that you "struggle with a sense of direction." I don't know that TDD will help you there. I find it's a great help for low-level design decisions, but not so great for architecture decisions. Adding TDD to a directionless project sounds a bit like having a baby to save a marriage - unwise. Hopefully I misread your intention.

Answer 6

Yes, it's never too late to start using TDD. I have introduced TDD to a commercial project that was already running for five years when I joined, and it was definitely a good decision.

While you are new to the technique, you should probably concentrate on using it for the code that you are writing from a clean slate - new classes, new methods etc. Once you got a hang on it, start writing tests for code that you change.

For some of the code, the latter might prove to be difficult, because the code you have written until now is unlikely to be written with testability in mind. There are some techniques to deal with that, but it's probably too early to care about them.

If you are missing a sense of direction, though, I doubt that TDD will help you a lot. You might want to look into Acceptance Testing instead, which is at least as important as unit testing, and will help you focus on the functionality of the system instead of single units of code. The TDD book by Lasse Koskela is a good introduction to both techniques.

Another technique that might help you is the Extreme Programming planning game, where you put pieces of functionality on index cards and prioritize them. I typically notice that getting ideas out of my head and in prioritized order helps me a lot in understanding where I want to go next.

Answer 7

Yes.

TDD makes it easier for other people to understand the code, as well as it gives the application a better design over time

Answer 8

Absolutely.

Introduce TDD to new code and if time allows, introduce "Comment Driven Design" with your existing code if it's not already tested.

• Comment out the block of existing code you need to test
• Write your test
• Uncomment your original code one statement at a time (if you have an if block, uncomment the entire block)
• Determine if your original code ultimately passes your test and if not, re-write to pass your tests accordingly

Answer 9

Writing tests for existing, working code that you don't plan to change doesn't fit with the thrust of TDD, which is to write tests that teach you about the system you're building.

My approach to bringing in TDD mid-stream has been to:

• write tests for all new features, and
• when changing a piece of code, write a test that covers the existing functionality (to make sure I understand it), then change the test before changing the code.

It can also be beneficial to write tests for code related to code you're changing - e.g., if you're altering a parent class, you may want to build tests around child classes first to protect yourself from potential damage.

Answer 10

Yes, you should. I'm currently working on a project that until recently wasn't covered with unit tests, but we decided that we should start testing our code, so we started writing them now. Unfortunately, I'm the only developer that practices TDD, others just write tests after writing their code.
Still, I found that practicing TDD helps me write better code, and I write it faster than before. Now that I learned how to do TDD, I just don't want to go back to writing code the way I used to.

Answer 11

In theory you were supposed to test first, but you didn't. In this scenario, contrary to others opinion, I wouldn't start with new features.

• Take advantage of the 80:20 rule, run a profiler, and put the test cases to the most frequently called piece of code.
• Put tests around the house jewel, gut, most-important code.
• Put tests around the annoying, always-breaking, recurrent déjà vu buggy code.
• Put tests around all bugs you come across before fixing the bug for failing test.

Warning: Putting test cases will require refactoring, which means you must fix something that's not breaking.

If you still love unit tests at this point, you'd be Red, Green, Refactoring on your own.