Forum: RSpec Any plans for Before-feature or Before-all steps in Cucumber?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ashley M. (Guest)
on 2008-12-02 16:59
(Received via mailing list)
Hi

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.

Ashley

[1]
http://blog.phusion.nl/2008/08/25/daemon_controlle...

--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
Joseph W. (Guest)
on 2008-12-02 17:29
(Received via mailing list)
Ashley M. wrote:
> Hi
>
> 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.

>
> [1]
> 
http://blog.phusion.nl/2008/08/25/daemon_controlle...
>
>
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.

--
Joseph W.
http://blog.josephwilk.net
Ashley M. (Guest)
on 2008-12-03 17:53
(Received via mailing list)
On 2 Dec 2008, at 15:26, Joseph W. wrote:

> 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!

   ServiceControllers.stop_all
   ServiceControllers.start_all

   at_exit do
     ServiceControllers.stop_all
   end

I don't like this though, it's asymmetric.


> 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).

Ashley

--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
Ben M. (Guest)
on 2008-12-03 18:59
(Received via mailing list)
Ashley M. wrote:
>> And Afterall is possible through: at_exit
>   # 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.

-Ben
Ashley M. (Guest)
on 2008-12-03 21:01
(Received via mailing list)
On 3 Dec 2008, at 16:59, Ben M. wrote:

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

Ashley

--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
Joseph W. (Guest)
on 2008-12-04 11:41
(Received via mailing list)
On Wed, Dec 3, 2008 at 7:01 PM, Ashley M.
<removed_email_address@domain.invalid>wrote:

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

http://rspec.lighthouseapp.com/projects/16211/tick...

--
Joseph W.
http://blog.josephwilk.net


>
Aslak H. (Guest)
on 2008-12-04 12:05
(Received via mailing list)
On Thu, Dec 4, 2008 at 10:40 AM, Joseph W.
<removed_email_address@domain.invalid>wrote:

>>> 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.
Matt W. (Guest)
on 2008-12-04 13:03
(Received via mailing list)
On 4 Dec 2008, at 10:04, aslak hellesoy wrote:

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

Sounds intriguing... what does AST mean / stand for?

Matt W.
http://blog.mattwynne.net
http://www.songkick.com
Aslak H. (Guest)
on 2008-12-04 13:08
(Received via mailing list)
On Thu, Dec 4, 2008 at 12:01 PM, Matt W. <removed_email_address@domain.invalid> 
wrote:

>
http://en.wikipedia.org/wiki/Abstract_syntax_tree
Joseph W. (Guest)
on 2008-12-04 13:08
(Received via mailing list)
Matt W. wrote:
>
> On 4 Dec 2008, at 10:04, aslak hellesoy wrote:
>
>> > 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.
>
> Sounds intriguing... what does AST mean / stand for?
Abstract Syntax Tree
http://en.wikipedia.org/wiki/Abstract_syntax_tree

--
Joseph W.
http://blog.josephwilk.net
Ben M. (Guest)
on 2008-12-04 18:56
(Received via mailing list)
aslak hellesoy wrote:
>         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.

-Ben
Aslak H. (Guest)
on 2008-12-04 20:11
(Received via mailing list)
>>
>>            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 topic is locked and can not be replied to.