[rspec-users] [cucumber] Cucumber and CI
matt at mattwynne.net
Wed Mar 4 12:09:39 EST 2009
On 4 Mar 2009, at 11:25, Dan North wrote:
> 2009/2/24 aslak hellesoy <aslak.hellesoy at gmail.com>
> On Tue, Feb 24, 2009 at 10:30 AM, Rob Holland
> <rob.holland at gmail.com> wrote:
> > On Tue, Feb 24, 2009 at 9:17 AM, Matt Wynne <matt at mattwynne.net>
> >> You can even use git commit --amend to commit on red (e.g at the
> end of the
> >> day) and then change that commit later.
> > While I think commit --amend is very useful, I'm not sure why you'd
> > bother to commit at the end of the day, knowing full well you were
> > going to amend it first thing tomorrow morning.
> Because the longer you wait, the more your code will diverge from your
> teammates'. If you don't commit often you rob them of the opportunity
> to reduce merge hell.
> This is the money line for me.
> There's a lovely CI pattern I've seen in the centralised SCM world
> (with Java, but that's less important) that I'm surprised hasn't
> been mentioned. Before I describe it I'd like to take this back to
> first principles.
> The point of continuous integration is to keep each individual
> integration small and avoid less frequent big integrations, because
> that's where the pain happens. Syncing up once per story or feature,
> which could easily be several days work, strikes me as a retrograde
> step. The fact that DSCMs like git or hg allow you to do this
> doesn't make it a good thing. There are many fantastic reasons to
> use DSCM - modelling IBM Rational ClearCase "best practice" usage
> patterns shouldn't be one of them.
> Anyhoo, it seems to me the problem we are discussing is the coupling
> between checking in an unfinished scenario and failing the build.
> The solution I've seen - scaling to projects with tens of developers
> and thousands of scenarios - is to separate in-progress features
> from finished ones, and build everything.
> If an in-progress scenario fails then the build carries on. If a
> completed scenario fails it causes the build to fail. There is a
> nice corollary to this whereby you fail the build if an in-progress
> scenario accidentally passes. This is because you usually want a
> human to find out why. In cuke-land you would do this at a feature
> level rather than a scenario level since the convention is to have
> one feature (with multiple scenarios) per file.
> Marking a feature as done can be as simple as moving it between two
> directories (called in-progress and done), renaming the feature
> (from openid_login.in-progress to openid_login.feature) or having
> an :in_progress tag on a feature until it's done.
> In Java-land I prefer the first model because I can point the same
> junit task at either the in-progress or done directories and just
> change the failOnError flag.
Thanks for your thoughts, Dan. Cucumber 0.2 tags are ideal for this
sort of filtering. I'm going to look at adding a 'two tier' feature
run to our build.
More information about the rspec-users