TDD and DDD while still understanding the domain

Question

When you are starting a new project from scratch using DDD, and still isn't very confortable with the domain, TDD comes at a price. While you're still understanding the details of the domain, you figure out a lot of stuff you've done wrong, like a method that makes more sense in some other class, or adding/removing parameters from a constructor, and many other changes.

These changes are VERY frequent, specially in the beginning. Every change usually (and hopefully) requires some changes in the unit tests, which increases cost of change (which, as I said before, is stil very frequent).

My question is: Is TDD worth the cost, even in situations where there is still lots of change happening, but there's hope they will get less frequent (once we have better insight of the domain, for instance) soon?

Answer 1

While you're still understanding the details of the domain, you figure out a lot of stuff you've done wrong, like a method that makes more sense in some other class, or adding/removing parameters from a constructor, and many other changes.

The process of understanding a domain is a design process, and it is helped by TDD, which you must understand is a design technique.

That method which makes more sense in some other class - you come to realize this quickly, more quickly, using TDD, because the first thing you do in writing the method is to write a test for it. When you write that test, you'll see that (for instance) you need to pass in a lot of members from the other class, and that will tell you - before you've even written the method - "Hey, this belongs over there!"

Use TDD to reduce the churn you're describing. It won't eliminate it, but it will reduce it, because you're doing design in the micro, on demand, as needed. It's Just-In-Time Design.

Answer 2

If you're at the point where you are still designing your domain model components at a relatively high level, then you shouldn't be writing unit tests yet. You need to have an understanding of the problem domain, and the responsibilities of your classes before you can start writing any code.

If you are at the point where you are fiddling with constructors and parameters in your classes, then TDD should not be thought of as a cost - it is helping you discover and fix problems in your design. It is an investment in a better object model and less maintenance down the road.

Also, if you're using a refactoring tool like ReSharper or CodeRush, I find that most of the early changes are really not that bad - just minor inconveniences.

Answer 3

I believe so. Part of Test Driven Development is that you're only building what you need to build - only what's required to make the tests pass. So, if you need to change something in the code due to a clearer understanding of the domain, you may have less to change with a TDD approach than without because you haven't spent time building unnecessary things.

There are other advantages as well - you know that the part of the code that you didn't change still works, since it's already got tests. Even if you rewrite 50% of the code, you'll know that your other 50% works. Also, you know that the code is testable - you've been designing it to be tested the whole time. It's often a huge pain to add unit tests to code that wasn't designed to have any - it's usually written in a way that's very difficult to test. Code that's made to be tested from the beginning is much better.