Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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?

share|improve this question
2  
Why do you think this is a good idea ? What sort of env are you working in, commercial, enterprise, safety critical ? –  Phil Kirkham Dec 14 '12 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 Dec 14 '12 at 2:54
    
Who is doing the approving ? What do you mean by 'approve' ? –  Phil Kirkham Dec 14 '12 at 3:47
    
@Phil Kirkham any team member can cab approve tests –  Nutel Dec 15 '12 at 19:31
add comment

4 Answers

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.

share|improve this answer
    
And if you are doing pair programming as well then review of code and tests is happening all the time... –  Phil Kirkham Dec 14 '12 at 12:38
3  
+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 Dec 14 '12 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 Dec 14 '12 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 Dec 16 '12 at 14:14
add comment

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 ?

share|improve this answer
add comment

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.

share|improve this answer
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 Dec 14 '12 at 19:45
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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