Comments on: Tag-Team Programming http://jkarlsson.com/blog/2006/05/18/tag-team-programming/ Agile Introvert Sat, 04 Sep 2010 12:18:11 -0400 http://wordpress.org/?v=2.8 hourly 1 By: Joakim Karlsson http://jkarlsson.com/blog/2006/05/18/tag-team-programming/comment-page-1/#comment-4 Joakim Karlsson Tue, 06 Jun 2006 08:59:54 +0000 http://www.jkarlsson.com/blog/2006/05/18/tag-team-programming/#comment-4 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. 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.

]]> By: Jacques http://jkarlsson.com/blog/2006/05/18/tag-team-programming/comment-page-1/#comment-3 Jacques Tue, 06 Jun 2006 00:19:24 +0000 http://www.jkarlsson.com/blog/2006/05/18/tag-team-programming/#comment-3 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 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

]]>