[rspec-users] [Cucumber] The User Story File
matt at mattwynne.net
Sat Nov 8 09:44:17 EST 2008
On 8 Nov 2008, at 02:30, David Chelimsky wrote:
> On Fri, Nov 7, 2008 at 8:53 PM, Josh Knowles <joshknowles at gmail.com>
> Next step ....
> Write a post commit hook to fire a message off to your build machine
> and have it run all the scenarios and email you the results. Sometimes
> everything will just pass. Sometimes you'll know you have new work to
> Any takers?
> And if you can train the business folk to make changes to their own
> branch (or maybe give them all their own forks - might be simpler) ...
> man - this opens up a ton of opportunity.
I've been thinking about this a lot.
Assuming you have a stakeholder who can check changes to feature
files, you're going to get a borked build sooner or later - it's
unlikely they'll change requirements and the code will magically
adjust itself! (not for a few years anyway!)
I guess like you say (and I hadn't thought of this) the right idea is
to get the stakeholder to check in their changes in a different branch
to the one in which the developers are hacking on the actual changes.
That way you can have a build on the stakeholder branch which is often
broken, but the breakages are like a 'todo list' for the developers -
it's basically your WIP. And you can have another build on the
developers' branch which is sacred and people get the usual
punishments for breaking.
I think there's a nice synergy to be had here between cucumber, git
and cruisecontrol.rb that will help you have a really lean workflow.
More information about the rspec-users