I'd question the wisdom of checking into an integration server every couple of minutes. I'm not sure if you meant that but if you did then I think these sort of checkins have to be in bigger chunks. The reason is that each checkin to an intergration server is asking my colleagues to checkout my code and integrate it into their current work. So everything I check in to the intergration server should be fit for them to use, and ideally it should have been reviewed (self review, or even better a bit of peer review - easy enought if pairing). You just can't do that in 2 minutes. IMO a complete scenario is about the smallest size chunk to integrate with, and a complete feature about the largest
Of course if your using Git (or any distributed vcs) you can just branch, commit locally and rebase from the master. If you want to push to get a backup as well, you can always have a backup target in addition to your integration target. If your not using Git (or something similar) locally I'd highly reccomend that. I think its reasonable to make failing steps pending for an integration commit, but its not something I would like to do regularly, much prefer to wait a bit longer before integrating and make them green. I really don't like working with more than 1 failing step, but find that occasionally I end up doing that (normally because a new step prompts a refactoring of and older step and that then breaks as well) HTH Andrew 2009/2/23 Yi Wen <hayafi...@gmail.com> > Wait for an hour before I can checkin something is still too long for me. > I'd like to checkin every couple minutes most of time. > > But I think to make each step just pending first and then make it green > when I finish implementation for the step makes sense. I probably will still > use unit tests passing as checkin points. > > Thanks > > Yi > > On Sun, Feb 22, 2009 at 3:36 PM, aslak hellesoy > <aslak.helle...@gmail.com>wrote: > >> On Sun, Feb 22, 2009 at 8:47 PM, Yi Wen <hayafi...@gmail.com> wrote: >> > The rhythm for wrking with cucumber advertised by http://cukes.info/ is >> to >> > write tests that fails first, then code that fixes it. Now my question >> is, >> > what is the implication when combine this with Continuous Integration? >> > >> >> * Nobody checks in code with failing tests (cucumber features, rspec >> tests, anything else). >> * If someone accidentally does, CI will run all tests and tell the team. >> >> > We all know when we do TDD/BDD in unit level, one test can be fixed >> fairly >> > quick in a coupe minutes and we can check in and kick off a build. It is >> a >> > ideal scene for doing CI: frequent checkin and fast feedback on build >> > results. >> > >> > Cucumber, as far as my understanding goes, works on feature level. It >> could >> > take people days to finish a cucumber feature. In the meantime, the >> cucumber >> > test remains broken. What do we do then? We cannot check in any code >> because >> >> A feature typically consists of several scenarios. You don't have to >> implement all scenarios before you commit. You don't have to write all >> scenarios when you start working on a feature. I recommend you never >> have more than one yellow scenario at a time. >> >> The same goes for scenarios, which consist of several steps. >> >> I recommend you commit every time you have made a step go from yellow >> to green (via red). >> This way, many successive commits will gradually build the whole feature. >> >> In my experience, getting a step to go from yellow to green rarely >> takes more than an hour (usually less). >> Is there anything preventing you from working this way? >> >> Aslak >> >> > that'll break the build. So we can only checkin code after several days? >> It >> > doesn't sound right to me. Any takes on this issue? Thanks in advance. >> > >> > Yi >> > >> > >> > >> > _______________________________________________ >> > rspec-users mailing list >> > rspec-users@rubyforge.org >> > http://rubyforge.org/mailman/listinfo/rspec-users >> > >> >> >> >> -- >> Aslak (::) >> _______________________________________________ >> rspec-users mailing list >> rspec-users@rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
