Is it proper TDD practice to design your model before you write tests, or write tests that design your model?

I am building a DDD system and we have all the requirements on paper for the system already set. There is a disagreement on how we go about building our domain model that I need an opinion on.

My preference is to take the requirements and sketch out a basic domain model with the outline for the classes, their properties and behaviors and relationships on a whiteboard or visio. I then take that and start building unit tests that I use to build and test my model out piece by piece.

My coworkers seem to think this is not good TDD+DDD practice. T开发者_Go百科hey think you should not sketch out anything and starting building test, and design your model as you go through the "feel" of the tests.

Which one is considered "Proper" TDD technique when building a DDD model?

Like any kind of software engineering question, the answer is often "a bit of both".

You can't really write any tests unless you have some idea of what it is you're going to be testing, but you can also use your tests to influence your model design. Maybe this all happens inside your brain, or maybe you document the process, but (in my opinion) you're going to have to use both ideas in the end.

Personally, I would do a couple of use cases, take a stab at the domain model, then write tests for it and see what design problems the tests throw up. Rinse and repeat. This should all be done in collaboration with the rest of the team.

I don't see how you can write a test without having any knowledge of the data items you're talking about.

 Thing myThing = getThingById( 87 );
 assert(Thing is Blue);

without some knowledge of the existence of a Thing or that it has an id and a colour you can't write the test. In other words, in writing even the simplest test you have in your head at least an embryonic Data Model. Sketching that informal model down may help you to reason about your tests.

The trick is to avoid getting sucked into detailed implementation before writing the tests, so I can understand why folks are giving the advice to do only Tests.

A question that interests me - given that the same tests could be satisfied by many different Data Models (think about denormalisation) at what stage do we start to build a better Data Model?

If I understood you correctly you want to start coding before doing any design. That is just wrong. For agile development, you need to do some design before doing anything else. Off course, it should be as flexible as possible, and shouldn't go much into details. Details are refined through unit tests.

One of the most important benefits of TDD is that it gets you to think about your application in ways you might not otherwise, just like DDD and many other practices we try in our development. The thinking in detail, without TOO much detail, is what is most important.