Is it good practice for TDD to develop your model before writing tests or writing tests that develop your model?

Question

I am creating a DDD system, and we have all the paper requirements for an already installed system. There is disagreement with how we are going to build our domain model, on which I need an opinion.

My preference is to accept the requirements and outline a basic domain model with a path for classes, their properties and behavior, and relationships on a whiteboard or visualization. Then I take this and start building the unit tests, which I use to build and test the model in parts.

My colleagues seem to think that this is not good practice for TDD + DDD. They think that you should not jot down something and start building a test, and design your model when you pass the “feeling” of the tests.

Which one is considered the "correct" TDD technique when building the DDD model?

Answer 1

Like any programming question, the answer is often "a little bit to both."

You cannot write any tests if you have any idea that you are going to test, but you can also use your tests to influence the design of your model. It may all happen inside your brain, or maybe you are documenting the process, but (in my opinion) you will have to use both ideas at the end.

Personally, I would make several use cases, take a hit on the domain model, then write tests for it and see what design problems arise during testing. Rinse and repeat. All of this should be done in collaboration with the rest of the team.

Answer 2

I don’t see how you can write a test without knowing about the data elements that you are talking about.

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

without any knowledge of the existence of Things or that it has an identifier and color, you cannot write a test. In other words, when writing even the simplest test, you have at least an embryonic data model in your head. Sketching this informal model down can help you ground your tests.

The trick is not to get involved in a detailed implementation before writing tests, so I can understand why people give advice to do only tests.

The question that interests me is, given that the same tests can satisfy many different data models (think about denormalization), at what stage do we begin to create a better data model?

Answer 3

If I understand correctly, you want to start coding before doing any design. This is simply wrong. For quick development, you need to do some design before doing anything else. Of course, it should be as flexible as possible and should not delve into the details. Details are specified using unit tests.

Answer 4

One of the most important advantages of TDD is that you need to think about your application in a way that you could otherwise, like DDD and many other methods that we are trying in our development. The main thing is that we think in detail, without much attention.