[rspec-users] [cucumber] Cucumber and CI

Andrew Premdas apremdas at gmail.com
Mon Feb 23 09:56:12 EST 2009

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)



2009/2/23 Yi Wen <hayafirst at 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.hellesoy at gmail.com>wrote:
>> On Sun, Feb 22, 2009 at 8:47 PM, Yi Wen <hayafirst at 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 at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/rspec-users
>> >
>> --
>> Aslak (::)
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090223/fab50049/attachment.html>

More information about the rspec-users mailing list