We are currently starting with TDD and we want to work in parallel in two programmers - one for writing test (Programmer A) and one for writing actual code (Programmer B). Problem is, how to synchronize our work.

Let's say A writes first test method, so B can start working on actual code. Our current workflow is that A will do commit/push, and B will pull his changes. In time it's bit annoying, because after every change in test (new test method/bug in current test method/some other update) requires commit/push/pull and it interrupts both developers...

Is there some "best practices" for TDD? Some synchronization between their codes, mirroring, already existing tool etc? Thanks for any tip!

  • 8
    Wow. One person writing only tests and another writing only the associated code is really weird. I find that so misguided that setting up the proper version control workflow is the least of your problems. Commented Jan 26, 2015 at 8:51
  • 1
    Can you please be more specific? Why do you think it's weird? And what do you suggest? Do both in one person? Or divide methods between two programmers, so everyone will write half of the tests and actual code for them? Commented Jan 26, 2015 at 8:58
  • 1
    @PavelŠtěrba you might consider sitting down together and writing BDD-style stories (just the stories, not the actual tests) and then dividing the workload up from there.
    – Hey
    Commented Jan 26, 2015 at 9:34
  • possible duplicate of Difference Between Unit Testing and Test Driven Development
    – gnat
    Commented Jan 26, 2015 at 10:06
  • 3
    @gnat: I think that other question might help the OP to understand better what he is asking, and if he is really asking the right question, nevertheless it is clearly not a duplicate (not even close).
    – Doc Brown
    Commented Jan 26, 2015 at 10:17

1 Answer 1


In TDD, writing tests and code is interwoven, the cycles are typically very short, sometimes minutes, sometimes less. And TDD is a whitebox technique - when writing the next test, you know exactly what is missing in the current state of the implementation and you design the test exactly for this case.

So if you really want to try this with two developers, your best shot would probably be doing pair programming: sit both in front of the same screen (or use a screen sharing software), and do it together. That way, there will be no VCS involved, which solves any of your synchronization problems.

  • 1
    In your pair programming, you may want to experiment with the ping pong pattern; it is similar in some ways to what you initially asked about. Commented Jan 26, 2015 at 9:51
  • Ok, let's say we will share our screen (or sit together in front of it), we have to work both on test and then both on implementation - something what I can do without pair programming too - am I right? So there is no good workflow how to work in parallel? Commented Jan 26, 2015 at 10:28
  • @PavelŠtěrba sure there is... figure out what needs to be done, divide the work up, work on it separately. IME this works fine (honestly never thought about trying to do it any other way).
    – Hey
    Commented Jan 26, 2015 at 10:39
  • Ok, so is this valid TDD workflow? 1.) Sit together, determine how some method should work. 2.) Work on test AND on implementation in parallel. 3.) Run test to prove that implementation is right. Or is it necessary in TDD to write tests first and implementation after, against those tests? Commented Jan 26, 2015 at 10:48
  • @PavelŠtěrba 1) sit together and write at least 2 BDD stories for different feature sets (but not the actual tests) and decide which story each person will work on; 2) each person does the usual BDD thing (write tests, confirm tests fail, write code, confirm tests pass); 3) push your changes, whoever finishes last gets to resolve any conflicts.
    – Hey
    Commented Jan 26, 2015 at 10:58

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.