2

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!

Carl Manaster
  • 4,173
  • 18
  • 31
Pavel Štěrba
  • 319
  • 1
  • 3
  • 8
  • 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. – Kilian Foth Jan 26 '15 at 08: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? – Pavel Štěrba Jan 26 '15 at 08: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 Jan 26 '15 at 09:34
  • possible duplicate of [Difference Between Unit Testing and Test Driven Development](http://programmers.stackexchange.com/questions/59928/difference-between-unit-testing-and-test-driven-development) – gnat Jan 26 '15 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 Jan 26 '15 at 10:17

1 Answers1

8

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.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • 1
    In your pair programming, you may want to experiment with the [ping pong pattern](http://c2.com/cgi/wiki?PairProgrammingPingPongPattern); it is similar in some ways to what you initially asked about. – Carl Manaster Jan 26 '15 at 09: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? – Pavel Štěrba Jan 26 '15 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 Jan 26 '15 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? – Pavel Štěrba Jan 26 '15 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 Jan 26 '15 at 10:58
  • @PavelŠtěrba: TDD was probably not designed to be used the way you suggested it, it is IMHO more an *implementation* technique than a testing technique. But why not just try it out how good it works for your team, especially the way suggested by CarlManaster? Note that he also suggested a pair programming approach to TDD, just like me. – Doc Brown Jan 26 '15 at 15:41