Has anyone looked at hooking up the Story Runner to Autotest?
Currently, the autotest hooks that rspec uses explicitly runs ./script/
spec, which when pointed to a story runner file doesn’t do anything.
(In fact, the generated spec.opts has an incompatible --format option
changing progress to just p works as it maps to plain in story runner)
Here’s how I think it can be mapped. I have a fairly simple convention:
Match stories/stories/(.*), rerun stories/stories/basename($1).rb
(i name my story files with .story extension)
Match stories/(helper|all).rb, rerun stories/all.rb
Match stories/steps/(.*)_step.rb, rerun stories/stories/
basename($1).rb
You can be fancier for steps if you like to break them up, like
looking into which Story Runner uses those steps.
Can Story Runner run a specific scenario in a story? Like how Spec
Runner can just execute a particular example.
Regards,
Kamal
p/s: I’m using rstakeout currently to run my stories and autotest to
run my specs. It’ll be great if they can context-switch in the same
autotest instance.
The only solution I have is trying to build much smaller stories so that
they run a bit quicker, though this can get messy.
I would absolutely love to be able to run changed scenarios upon saving,
like how autotest works for the specs.
Has anyone achieved this yet?
That would be very difficult to do and to do well (with autotest or
RSpactor) since stories cover a complete vertical slice of the
application, and it’d be almost impossible to know what source file
(or method) affect will what stories.
Continuous integration works very well for this. Let another machine
pull an update (or you can push an update) and it runs the specs and
stories. When I was at Atomic Object I wrote a small growl notifier
which received updates from our continuous integration server telling
it when something failed. It was beautiful. Of course this was really
easy to write since the continuous integration server was written in a
way that allowed you to attach listeners (and remote monitors) to it
over the network.
That would be very difficult to do and to do well (with autotest or
RSpactor) since stories cover a complete vertical slice of the
application, and it’d be almost impossible to know what source file
(or method) affect will what stories.
Sure, I agree, but I think it would still be incredibly useful even if
it ran a single scenario every time you edit that scenario - not
necessarily the source files that the scenario would “operate” on.
Continuous integration works very well for this. Let another machine
pull an update (or you can push an update) and it runs the specs and
stories. When I was at Atomic Object I wrote a small growl notifier
which received updates from our continuous integration server telling
it when something failed. It was beautiful. Of course this was really
easy to write since the continuous integration server was written in a
way that allowed you to attach listeners (and remote monitors) to it
over the network.
I’ve already got TeamCity (highly recommended) running for both stories
and examples every time I check into SVN. I’m doing things as
test-driven as possible , and more times than not it’s a story driving
development rather than a spec. Test driving things this way means I
get to run the stories all the time, and a bit of automation would be
awesome.
Hell, I’d settle to just be able to execute a single scenario by hand at
this point. Running an entire story is still too large for me sometimes
=)
… I think it would still be incredibly useful even if
it ran a single scenario every time you edit that scenario - not
necessarily the source files that the scenario would “operate” on.
You can pull this off pretty easily with rstakeout.