A while back I got the opportunity to do some coding together with a colleague of mine that works in North Andover. I am situated in Malmö, Sweden, myself so we had a time difference of six hours to overcome. Using tools like NUnit and FIT/Fitnesse we were able to get quite a good flow even if the circumstances under which we had to work were far from optimal.
A somewhat idealized day could look something like this for me:
When I got in to work I got the latest source, built it, and ran the suite of acceptance tests that we had created earlier. By doing that I got a really good overview of what had happened while I was away from the office. The currently failing acceptance test would act as a marker that showed me how far we were into development. I could also quite easily see the progress since the last day. What new tests were passing that weren’t passing yesterday? Were there any changes to the acceptance tests themselves because my colleague had found some changes in the way things ought to work?
When I had reviewed the changes to the acceptance tests, I could take a look at the NUnit tests that had been added or modified during the night. This gave me a good view of what classes had been modified, and in what way. The unit tests acted very well as more low level documentation on what behavior had been worked on during the night. Now I could do a review of the changes made and see if I could see some refactorings that would make things a bit easier to read and make changes to.
Next, I would turn to the currently failing acceptance test. By starting to look at the code that performed the actual test, I could quite easily get a feel for what needed to be done next - make the acceptance test go a little bit further. I could now go on and start developing the next step, using TDD, and hopefully I could make a complete acceptance test pass.
Around 3 pm CET, my colleague would get to work and we could talk a bit on the phone, or using mail, or IM. During this time we could have a quick design session or discuss some other issues that had come up. After that I could go home, and my colleague could take over for the night.
What struck me when doing this was how much communication the tests were able to facilitate, both the acceptance tests and the unit tests. When the other means of communication where crippled, the tests could make up for a lot more than I had expected.
The acceptance tests:
- Provided a progress bar of sorts on how we were doing.
- Gave enough details on what had been done so one could get a quick overview of what had been done since last time.
- Gave a starting point for today’s work. Start implementing the currently failing feature.
The unit tests:
- Provided the details on what had been done since last.
- Provided low level documentation on any new classes that had been created since last.
When most other forms of communication were limited, it dawned on me how much about communication testing really is. Yes, testing is about asserting that your code behaves properly. Yes, TDD is very much a way to get a good, loosely coupled design. But it is also very much about communication. It is therefore important to keep the tests readable and to the point.
I would also like to get the opportunity to try out some long distance pair programming at some point as well, and see how that goes.
2 Responses to “Tag-Team Programming”
Leave a Reply
Recent Blog Entries
Interesting post. I have similar experience and would like to pick you brain on a couple of related problems my team is having for some time now:
How did you track the progress on the ATs in fitnesse?
This is one big issue that we have. We do TDD to the letter and get the ATs working as fast as we can. However this may mean stubbing things out or doing something the easy way not the right way. How do you know when an ATs is then not really finished, that it needs more refactoring…?
The bar is green! It does not function as a marker anymore ;-(
The other problem I see is how do you keep track of what ATs were running the night before or for that matter the previous run? The way we work is that we have 2 suites, the passing tests (not to be broken) and the in-progress tests (ok to break since they are always the ATs of the current iteration stories). We have a clear signal for the passing tests since they should always run. However it isn’t so clear anymore if you are breaking something that used to work in the passing tests.
We have a growing app developed by 9 developers. We are adding 30-50 tests each iteration.
BTW I supposed you were using your VCS tool to track changes. What VCS were you using?
Thanks
Ideally, we only make the acceptance tests pass by doing things the “correct way”. No stubbing things out. Touching the file system if we need to. Etc. Etc. That we leave to the unit tests where the TDD mantra applies IMO. If an acceptance test passes; to the best of our knowledge that feature is done.
In the scenario I describe here, we were only two developers and the tasks wasn’t bigger than could fit in our heads and a few notes. So that way, tracking progress wasn’t a problem. I do know of another team that are using CruiseControl(.NET) to generate Fitnesse reports for each build. That way you have the option of comparing the results for any two builds. That could be a way to track progress.
But at the end of the day I think you do need something other than just the tests if you want to track progress seriously. Although just the tests is a better communication channel than one would think.
We’re using subversion for version control and are quite happy with it.