TDD – Understanding ‘TDD is About Design, Not Verification’

bdddesigndevelopment-processtddunit testing

I've been wondering about this. What do we exactly mean by design and verification.

Should I just apply TDD to make sure my code is SOLID and not check if it's external behaviour is correct?

Should I use BDD for verifying the behaviour is correct?

Where I get confused also is regarding TDD code Katas, to me they looked like more about verification than design; shouldn't they be called BDD Katas instead of TDD Katas?

I reckon that for example the Uncle Bob bowling Kata leads in the end to a simple and nice internal design but I felt that most of the process was centred more around verification than design. Design seemed to be a side effect of testing the external behaviour incrementally. I didn't feel so much that we were focusing most of our efforts on design but more on verification. While normally we are told the contrary, that in TDD, verification is a side effect, design is the main purpose.

So my question is what should I focus on exactly, when I do TDD: SOLID, external API usability, or something else?

And how can I do that without being focused on verification?

What do you guys focus your energy on when you are practising TDD?

Best Answer

TDD code katas are about learning TDD practices and how they drive design (and learning good design in that way - yes, normally this means learning how to write SOLID code).

This means that TDD is about achieving good design - but having well designed code that is not solving a problem is useless. That's where verification comes in - this can be in many forms, BDD being one of them as one of many automated acceptance testing techniques.

Verification is about ensuring that the code written is solving the correct problem.

So, when doing TDD, focus on the design - make sure it is clean and SOLID.

But don't forget to add unit tests and acceptance tests (and any other tests that are deemed needed).