XpdWiki
| FrontPage |
| RecentChanges |
| XtC |
| FindPage |
| PageIndex |
| XpApprentices |
UserPreferences
Referenced by
DoingPairedProgra...
ShareSourceBetweenPairs |
|
| Your trail: | |
Try writing the test for the next piece of the task. Of course it will fail immediately. So write the first line as ....
fail("This ... test fails due to no code implemented");
Now imagine starting your day. Run TestAll? and see which tests fail ...
Run 100 tests 1 failure This massiveCalculationThingy test fails due to no code implemented.
PaulSimmons tried this pairing with Phil at an Xtc meeting. If you don't agree, or want to add something, edit this page.
XP seems to suggest ResponsibilityPerTask, such that an engineering task should be completed by one pair before source is handed on. Does this negate the need for the above? PaulSimmons
There's no need for it to be a "fail" test. It can just be a regular test, that fails because there is no code yet... -- PhilipCraig? I agree, but I do feel that the fail gives a good descriptive message - which although possible with assert, this is not encouraged by the syntax of assert. PaulS
Its useful to mention that this interesting comment was inspired from an artificial experiement at XtC where two new team members who had never seen the code had a go at taking on the next task. In a non-global team, this situation probably wouldn't occur because tasks would be finished in their entiretly without any loose ends remaining. Or in the the case that something didn't quite get finished as intended, the orginial members would be available to query. See ShareSourceOnGlobalProjects?
As an aside (more in line with the title), the common way for VisualAge teams to share source is to use the repository in the enterprise edition. Thus when you complete enough of a task, and all of your tests pass - you then release this code to the rest of the team (they will all get an indicator on their screen showing that they are not working with the currently released version).
This is a good selling point for VisualAge, but more generally I think this applies to any source control system - i.e: you only check-in (release) code when your tests pass (or at end of task). -- PaulSimmons
I think there is some confusion about check-in vs. release in other VCS's. Frank has used this term differently below. Perhaps you can both comment on this. -- TimM
Question - do they release an entire task, or do they release successful increments of a task (if it is a bigger one)? I'm not sure - and its something worth checking - that relates back to Paul's initial comment on embedding a failing test... -- TimM
I understand from the Wiki discussions that you should check in every time your unit tests pass, regardless of what changes you have made. This allows many refactorings to proceed in parallel. There seems to be a difference between checking your code back into the repository or version control system and actually making a release, which should be done through a bottleneck such as a Wiki.SingleReleasePoint?. This 'release' operation happens only when a task or user story is complete. How to implement this difference varies between version control systems. --Wiki.FrankCarver
Frank - that is a great reference to point out. I have added some additional comments to it about my experience with ownership as a token. Having written the question above I notice on the XP-FAQ that they talk about task normally taking 1-3 days however you should be integrating daily (or even sooner). So I agree with you (and this confirms my/our experience) that you run better in parallel if you can release sooner. However we have to be careful in our use of check-in and release as it differs in environments. I would say that you do small hops along your task keeping your tests working (we use FifteenMinuteTimeBoxes for this). When you get a significant chunk working you should be doing a release and reloading the entire system. (this way people get your proven changes, and you get other peoples proven changes). Now in VisualAge, everything you do is in the repository and other team members can see it if they want to, however its only when you release that they will get the code automatically. Having not used other VCS's in anger I am assuming that unless you check-in periodically, people don't see those changes (and its harder for you to back out of changes). I think this might be a mute point though, as I've rarely had people want un-released code off me (unless its a quick bug fix that you are still proving - however with UnitTestsUpFront? this doesn't happen right?). Releasing then becomes a consideration of:
- natural breaking points (unless you have completely finished the task in less than half a day anyway)
- how parrallel you want to run
- how much effort it takes to release.
Obviously releasing every 15 minutes its too much hassle, and doing it once a day limits how much you can parallize. In my experience 2-4 times a day is a good goal to aim for. Maybe you have some DeveloperExperience to further add on this -- TimM³ShareSourceBetweenPair So you finish your task and get 'All Tests ok'. You've had a good day. But in global software development, how do you hand on the source to the next pair? How can you save them that 10 mins at the start of their day playing 'catch-up'?
Try writing the test for the next piece of the task. Of course it will fail immediately. So write the first line as ....
fail("This ... test fails due to no code implemented");
Now imagine starting your day. Run TestAll? and see which tests fail ...
Run 100 tests 1 failure This massiveCalculationThingy test fails due to no code implemented.
PaulSimmons tried this pairing with Phil at an Xtc meeting. If you don't agree, or want to add something, edit this page.
XP seems to suggest ResponsibilityPerTask, such that an engineering task should be completed by one pair before source is handed on. Does this negate the need for the above? PaulSimmons
There's no need for it to be a "fail" test. It can just be a regular test, that fails because there is no code yet... -- PhilipCraig? I agree, but I do feel that the fail gives a good descriptive message - which although possible with assert, this is not encouraged by the syntax of assert. PaulS
Its useful to mention that this interesting comment was inspired from an artificial experiement at XtC where two new team members who had never seen the code had a go at taking on the next task. In a non-global team, this situation probably wouldn't occur because tasks would be finished in their entiretly without any loose ends remaining. Or in the the case that something didn't quite get finished as intended, the orginial members would be available to query. See ShareSourceOnGlobalProjects?
As an aside (more in line with the title), the common way for VisualAge teams to share source is to use the repository in the enterprise edition. Thus when you complete enough of a task, and all of your tests pass - you then release this code to the rest of the team (they will all get an indicator on their screen showing that they are not working with the currently released version).
This is a good selling point for VisualAge, but more generally I think this applies to any source control system - i.e: you only check-in (release) code when your tests pass (or at end of task). -- PaulSimmons
I think there is some confusion about check-in vs. release in other VCS's. Frank has used this term differently below. Perhaps you can both comment on this. -- TimM
Question - do they release an entire task, or do they release successful increments of a task (if it is a bigger one)? I'm not sure - and its something worth checking - that relates back to Paul's initial comment on embedding a failing test... -- TimM
I understand from the Wiki discussions that you should check in every time your unit tests pass, regardless of what changes you have made. This allows many refactorings to proceed in parallel. There seems to be a difference between checking your code back into the repository or version control system and actually making a release, which should be done through a bottleneck such as a Wiki.SingleReleasePoint?. This 'release' operation happens only when a task or user story is complete. How to implement this difference varies between version control systems. --Wiki.FrankCarver
Frank - that is a great reference to point out. I have added some additional comments to it about my experience with ownership as a token. Having written the question above I notice on the XP-FAQ that they talk about task normally taking 1-3 days however you should be integrating daily (or even sooner). So I agree with you (and this confirms my/our experience) that you run better in parallel if you can release sooner. However we have to be careful in our use of check-in and release as it differs in environments. I would say that you do small hops along your task keeping your tests working (we use FifteenMinuteTimeBoxes for this). When you get a significant chunk working you should be doing a release and reloading the entire system. (this way people get your proven changes, and you get other peoples proven changes). Now in VisualAge, everything you do is in the repository and other team members can see it if they want to, however its only when you release that they will get the code automatically. Having not used other VCS's in anger I am assuming that unless you check-in periodically, people don't see those changes (and its harder for you to back out of changes). I think this might be a mute point though, as I've rarely had people want un-released code off me (unless its a quick bug fix that you are still proving - however with UnitTestsUpFront? this doesn't happen right?). Releasing then becomes a consideration of:
- natural breaking points (unless you have completely finished the task in less than half a day anyway)
- how parrallel you want to run
- how much effort it takes to release.
Obviously releasing every 15 minutes its too much hassle, and doing it once a day limits how much you can parallize. In my experience 2-4 times a day is a good goal to aim for. Maybe you have some DeveloperExperience to further add on this -- TimM
I spent some time recently experimenting with CruiseControl. Deployment becomes a non-issue, you just leave it to the automated process. It's also really good at naming & shaming people into not checking in failing code - 5 minutes after you did it a "Build failed!!" email is sent out to all and sundry. A "successful build" message can also be a good reminder to re-sync for those teams using a pull-based system (eg. sourcesafe, CVS etc.). The downside is that you have to already have the right 'team process' in place such that all code is covered by tests, and you take SmallSteps?. If you're in a team where the attitude is 'I can't get this to work but I don't want to lose 2 days of (un-checked in) effort, so I'll check it in broken and fix it later', then be prepared for plenty of spam from your build machine. --DarrenHobbs³host³³date³February 19, 2002³agent³Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; T312461)³ShareSourceBetweenPairs
| Edit this page More info... Attach file... |
| This page last changed on 19-Feb-2002 12:54:23 GMT by unknown. |