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?

  • I miss read Uncle Bob statement: "The act of writing a unit test is more an act of design than verification" - (Robert C Martin). It actually means than yes we still do some verification but that's not the main purpose. I got it wrong when I wrote 'is about design NOT verification' which lead me to conclude that we should not be doing verification during TDD.
    – foobarcode
    Commented Oct 6, 2012 at 18:07
  • My question was also similar to stackoverflow.com/questions/3494961/…
    – foobarcode
    Commented Oct 6, 2012 at 18:13

5 Answers 5


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).


It might be useful to see a picture:

enter image description here

Note that acceptance tests (i.e. verification) sit outside of the usual TDD cycle. The unit tests insure that your code works, but the acceptance tests insure that the code meets the customer's requirements.

ATDD stands for Acceptance Test-Driven Development.

  • What about integration and regression tests? And how do you automate acceptance tests?
    – tdammers
    Commented Oct 6, 2012 at 16:42
  • 2
    @tdammers Acceptance tests on a library are fairly straightforward, especially with the help of mocks. Acceptance tests on applications can be done with tools like Selenium. Integration tests are just unit tests that involve multiple classes working together. Regression tests are just those tests that you run to make sure you didn't break anything; they are not necessarily separate tests in their own right. Commented Oct 6, 2012 at 17:10
  • I wouldn't call tests on multiple classes and methods "unit tests", but OK.
    – tdammers
    Commented Oct 6, 2012 at 17:38
  • 1
    @sigo: You may be taking Uncle Bob a bit too literally. While it's true that unit tests in TDD are meant to guide the design of your code (in large part by making your code testable, ahem), the point of unit tests is still to verify behavior. That's why they call them tests. You can't just "grow" a software architecture from tests; even Uncle Bob says that. Commented Oct 7, 2012 at 0:22
  • 1
    @RobertHarvey "Integration tests are just unit tests that involve multiple classes working together." Does that mean when doing integration tests we just replace all stubs and mocks in previous tests by real implementations and re-do the old tests again?
    – Songo
    Commented Oct 7, 2012 at 11:51

Verification is about ensuring that a product meets all of the requirements as they were specified. Test Driven Development, by itself, doesn't specify the quality of the tests written, and as such, can't guarantee that a product fully conforms to its specification. When you write your tests first, you tend to focus on producing software that is easily testable - you achieve a high amount of functional code coverage, and have an opportunity to think about what your API should look like by writing your test before you write the backing functionality.

When you are writing your tests, you should also think about verification - map your tests to your requirements, think about other code paths within your functions (achieving a higher statement or decision coverage). But TDD doesn't say anything about these - it just says that you should write your tests first and then write the minimal amount of code to make the tests pass. Without ensuring at least full requirements coverage of your tests and greater path coverage, your tests might not be suitable for verification purposes.

> tdd is about design not verification.

I would translate this to "the benefit of tdd is good design".

In tdd you concentrate on writing verification code.

By doing tdd (=writing tests in isolation before implementing the code) you get good design (=minimal coupling) automatically as a side effect.

Opposed to writing automated tests after implementing code you get verififcation as well but without the extra design benefit.


It is really about both, but the verification is a nice side effect which could be accomplished by writing the tests after the code. The real benefit of TDD and writing the test first is that it helps you flesh out the design by refining the design of each logical unit or business rule and building on the rest of the logical units without breaking the other units of the design and keeping them from becoming overly coupled.

For example some developers use the TDD approach almost like a "white board" where the tests and code all live in the same file initially. It gives a lot of freedom to evolve the logic with the tests, as well as test out ideas. Then as the design evolves the code is extracted out of the test module into the application itself.

The resulting tests can be used for verification as further refactoring is done.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.