The code I’m working on now is a server daemon that talks to Twitter,
an RSS feed, and some web pages. I’ve got mock implementations of
Twitter and the web stuff, which I start and stop with
daemon_controller[1]. I do all the setup in a Before block, but this
makes the feature runs agonisingly slow due to the time waiting for
everything to restart. I’m now starting a Merb app which will rely on
the database created by the server daemon, so it’s going to get even
slower.
Are there any plans to add BeforeStory or BeforeAll blocks to
Cucumber? With this I could start everything once and add reset code
to each daemon.
The code I’m working on now is a server daemon that talks to Twitter,
an RSS feed, and some web pages. I’ve got mock implementations of
Twitter and the web stuff, which I start and stop with
daemon_controller[1]. I do all the setup in a Before block,
All defined before blocks are run for each scenario so this would slow
down every scenario.
BeforeAll (Before running any feature) is currently possible through
putting something in your env.rb or really any ruby file that gets
required. It will be run once (and before anything else).
I use this to manage ferret/selenium. The before/afters being used to
tell the service to cleanup so we have clean environment for each test.
Could you do the same?
And Afterall is possible through: at_exit
BeforeFeature sounds like it could be useful for preparing services for
that specific feature and you don’t want them running for other
features. I guess currently the only way of achieving this is
separating those features and running them in separate cucumber runs.
This is what I have done with something similar, using --profile to run
different sets of features. I prefer this (in my experience so far) as
it allows me to re-use my rake tasks for setting things up and keeps
that setup from adding noise to my test code. I appreciate with mock
services your situation is slightly different.
BeforeAll (Before running any feature) is currently possible through
putting something in your env.rb or really any ruby file that gets
required. It will be run once (and before anything else).
I use this to manage ferret/selenium. The before/afters being used
to tell the service to cleanup so we have clean environment for each
test. Could you do the same?
And Afterall is possible through: at_exit
Yeah, I’ve had to resort to doing this, which makes the end of my
env.rb look like this:
#######################
Start everything up
#######################
require ‘support/service_controllers’
Note this relies on this file being loaded only once!
BeforeFeature sounds like it could be useful for preparing services
for that specific feature and you don’t want them running for other
features. I guess currently the only way of achieving this is
separating those features and running them in separate cucumber
runs. This is what I have done with something similar, using –
profile to run different sets of features. I prefer this (in my
experience so far) as it allows me to re-use my rake tasks for
setting things up and keeps that setup from adding noise to my test
code. I appreciate with mock services your situation is slightly
different.
I see what you mean, but it’s always useful to run all the features in
one run. ‘rake features’ should be the unambiguous, authoritative
decider of whether your code can go live (IMHO).
I agree with Ashley. In the past I have done multiple profiles just
as Joseph has suggested. I have then modified my features task to
serially run my different feature sets and profiles. With that you
do have one task you need to run. However, it would still be very
nice if these different profile types, even if not ran as the same
process, could be grouped into a single report and given then
appearance that it was one large process. I understand the problems
and difficulties of doing such a thing, but WDYT? If we think there
is enough value in such an aggregate feature set runner/report and
we can decide on the details then I would be willing to tackle it.
Sounds like there’s two issues here. One is grouping features into
run sets (eg fast-running, slow-running; needs an external service, is
self-contained) the other is running features in a certain mode (eg
against mock-services, against live services; using HTML interface,
using XML interface).
One solution to the first problem could be tagging the features/
scenarios:
Feature: blah
Groups: slow
As a…
Scenario: blah
Groups: twitter web
Or something. Maybe?
The second problem currently has to be handled as separate Cucumber
rake tasks with different --require options to load different steps.
I don’t have any multi-mode features though, so I haven’t had to worry
about this yet. I suspect the general problem (given all the
potential dimensions you could create) is currently unspecified and
the general solution is quite hard…
I still think having an authoritative ‘rake features’ is essential,
though.
If we think there is enough value in such an aggregate feature set
runner/report and we can decide on the details then I would be willing to
tackle it.
I think a nice way to facilitate one report from multiple cucumber runs
is
useful.
I’m currently resorting to 'cat’ing (yuck!) the different Cucumber
reports
to get one html report in the features rake task.
Currently when you pass ‘–out file’ to Cucumber it truncates the file.
We
could have it open the file for appending. That sounds like a simple
solution to forming one report from multiple runs.
You would still get the (minor) problem I have when 'cat’ing the files
(HTML
reports with multiple html heads).
given then appearance that it was one large process.
Where you thinking about giving the appearance of one process at the
report
level or the rake level?
Feature: blah
Groups: slow
As a…
Scenario: blah
Groups: twitter web
Or something. Maybe?
We currently have an issue on tagging but it will have to wait until
Aslak
has done his AST magic.
profile types, even if not ran as the same process, could be grouped into a
single report and given then appearance that it was one large process. I
understand the problems and difficulties of doing such a thing, but WDYT?
If we think there is enough value in such an aggregate feature set
runner/report and we can decide on the details then I would be willing to
tackle it.
I think a nice way to facilitate one report from multiple cucumber runs is
useful.
I think the way to go is to have a YAML formatter that can spit out
reports
as YAML. Then several YAML reports can be read in.
My plan with the AST work is that the AST itself stores the results, so
it
can be serialised and deserialised. This will make concatenating several
reports much easier.
As a…
Scenario: blah
Groups: twitter web
Or something. Maybe?
We currently have an issue on tagging but it will have to wait until Aslak
has done his AST magic.
Just a heads up - planning to get started on this around Dec 15th.
Note this relies on this file being loaded only once!
I see what you mean, but it’s always useful to run all the features in
one run. ‘rake features’ should be the unambiguous, authoritative
decider of whether your code can go live (IMHO).
Ashley
I agree with Ashley. In the past I have done multiple profiles just as
Joseph has suggested. I have then modified my features task to serially
run my different feature sets and profiles. With that you do have one
task you need to run. However, it would still be very nice if these
different profile types, even if not ran as the same process, could be
grouped into a single report and given then appearance that it was one
large process. I understand the problems and difficulties of doing such
a thing, but WDYT? If we think there is enough value in such an
aggregate feature set runner/report and we can decide on the details
then I would be willing to tackle it.
On 3 Dec 2008, at 16:59, Ben M. wrote:
thing, but WDYT? If we think there is enough value in
such an aggregate feature set runner/report and we can
decide on the details then I would be willing to tackle it.
I think a nice way to facilitate one report from multiple cucumber
runs is useful.
I think the way to go is to have a YAML formatter that can spit out
reports as YAML. Then several YAML reports can be read in.
Yeah, that was actually exactly what I was thinking!
My plan with the AST work is that the AST itself stores the results,
so it can be serialised and deserialised. This will make concatenating
several reports much easier.
Ahh, I see. So the report concatenatenater would just have to load up
all of the serialised ASTs and send them to one formatter? So, I’m
guessing you want to wait on this until after the AST work is done…
I’ll open up a ticket in lighthouse for this regardless.
understand the problems and difficulties of doing such a
I think the way to go is to have a YAML formatter that can spit out
I’m guessing you want to wait on this until after the AST work is
done… I’ll open up a ticket in lighthouse for this regardless.
Spot on
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.