I am going to adopt TDD in our team and one of the ideas I have is to review tests first. So one would write interfaces, mocks, and tests first, submit them for a code review and once interfaces and tests (think specification) are approved an actual implementation can be written (theoretically, can be done by another developer). I wonder how viable this idea is?

  • 2
    Why do you think this is a good idea ? What sort of env are you working in, commercial, enterprise, safety critical ? Commented Dec 14, 2012 at 2:22
  • the intention was to at first think and agree about pre/post-conditions and once tests are approved we know that a code that meets this specification defined via tests meets our requirements
    – Nutel
    Commented Dec 14, 2012 at 2:54
  • Who is doing the approving ? What do you mean by 'approve' ? Commented Dec 14, 2012 at 3:47
  • @Phil Kirkham any team member can cab approve tests
    – Nutel
    Commented Dec 15, 2012 at 19:31

4 Answers 4


The Three Laws of TDD

  1. You are not allowed to write any production code until you have first written a failing unit test.
  2. You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing.
  3. You are not allowed to write more production code that is sufficient to pass the currently failing unit test.

...These three laws lock you into a cycle that is, perhaps, thirty seconds long....Round and round the cycle you go. Adding a bit to the test code. Adding a bit to the production code. The two code streams grow simultaneously into complementary components. The tests fit the production code like an antibody fits an antigen.

Source: The Clean Coder: A Code Of Conduct for Professional Programmers

To me this suggests that actually you shouldn't be spending time reviewing unit test code on an individual level, as there wouldn't be enough flexibility or speed in that approach to gain any of the benefit. It should be a fast process of multiple iterations. Theses iterations inform the programmer as they are writing code about the changes they are making, improving the code.

Instead review unit tests and final code submissions together. So long as the programmer understands the requirements correctly this should allow you to still have reviews (as you should of course) but keeping the advantages of TDD.

  • 1
    And if you are doing pair programming as well then review of code and tests is happening all the time... Commented Dec 14, 2012 at 12:38
  • 4
    +1 for cycles. TDD is done in cycles: unit tests are very close to the code (and so solution and architecture) that is evolving. So it would make no sense to have unit tests written once and freeze them forever. It would however, make more sense to agree on some high-level acceptance tests in advance.
    – dzieciou
    Commented Dec 14, 2012 at 12:40
  • 1
    I'm not sure how to parse that last paragraph. It may need a period after "together" or after "correctly".
    – user246
    Commented Dec 14, 2012 at 16:49
  • Period added to last paragraph. I wrote this before the office Christmas party so it was slightly rushed :(. @Phil yes I would agree about the paired approach being an optimal style of TDD if tight reviews were important.
    – Tom
    Commented Dec 16, 2012 at 14:14

Doesn't TDD mean the developer has the design suggested to him as he codes the tests rather than being handed a spec to write code to ? Don't you then also miss the dev having the conversation with the customer to understand their needs ?


I think Tom's answer explains why TDD doesn't work well with reviewing unit tests ahead of time; unit tests become part of the implementation process in TDD, and are part of a tight cycle between testing and implementation. In other words, you can't write unit tests before coding if you are using TDD.

Reviewing Cucumber-style acceptance tests, however, makes sense before implementation starts. The purpose of these tests is to make sure that the customer / business owner and the developer are on the same page, and that should happen before implementation. Defining interfaces and reviewing them might also make sense, especially if two teams working in parallel. These should be relatively easy sells to the team.

I would be hesitant to design mocks ahead of time as well, as they will naturally be developed during TDD (if TDD is done right); however, doing mocks ahead of time could be useful for encouraging code reuse, so it's not a bad idea - just might not be worth the process pain. Developing mocks ahead of time could get some push-back from the dev team, if they don't fully grasp why they would be useful. I'd personally try this with just the acceptance tests and interfaces first, and then see if the team felt that adding mocks to the up-front requirements would help. This might mean more pain up-front if testers rely on developers to write mocks and devs aren't doing it, but I suspect it will result in more buy-in in the end. Also, you might find that good mocks are a natural result of TDD, and your testers are getting mocks without having to really push devs to create them. If it's the devs writing the mocks that are pushing for them to be developed first, then you already have buy-in and should give it a try.

In general, I'd be sure to get team buy-in on any up-front requirements. If the team doesn't want to do the work or believe that it might help, it won't work.

  • 2
    There is a "cart before the horse" aspect to this. Most of us are unable to anticipate every dependency before the software is written, which is one reason why the process is iterative.
    – user246
    Commented Dec 14, 2012 at 19:45

I hate such persons that says "This is not a Scrum", when they were asked "Hey, we have a scrum without stand-ups, so how could we do [something]".

I am going be such a nasty person when I say "That is not a TDD what you have described". The TDD has some strict rules, but is it really a big reason to follow them all? I think – no.

Nutel, the idea you presented is viable, but it depends how you will implement it. You should not be restricted to when to write the unit tests: before or after the production code. Maybe it would be better to start from integration tests? Or from the system integration or acceptance tests?

Or, maybe you do not need the tests at all, and it would be better to run the design workshops and just to discuss better what we need from the new functionality.

It depends on situation on you project.

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.