[rspec-users] [cucumber] Cucumber and CI

[Matt Wynne]

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>  
> wrote:
> >
> >> 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.


Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com