Drastically faster test suite for Cucumber-Ruby

[aslak hellesoy]

Good news!

https://travis-ci.org/cucumber/cucumber/builds

See how much faster the Cucumber test suite runs?

Most aruba features under /features now run in-process (except the ones tagged with @spawn), and the startup time saves a lot of time.

More details in the Aruba README:

https://github.com/cucumber/aruba

Aslak

[Steve Tooke]

On Thursday, 18 April 2013 at 23:40, aslak hellesoy wrote:

Good news!

https://travis-ci.org/cucumber/cucumber/builds

See how much faster the Cucumber test suite runs?

Most aruba features under /features now run in-process (except the ones tagged with @spawn), and the startup time saves a lot of time.

Thats brilliant, thanks Aslak.  

Steve

[Oleg Sukhodolsky]

I'm second to Steve.  It is awesome speedup! Thank you for this! 

Oleg.

Steve

--
You received this message because you are subscribed to the Google Groups "Cukes Devs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes-devs+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jarl Friis]

It's a fantatic speedup, great stuff.

I know I am far too late on this, sorry for that. I should have shared
my opinion on issue 148 (I thought I was watching the project; now I
do) and for that reason I expect no one will listen to me now, however
I still would like to comment (on the changes to aruba).

For the sake of Aruba, I think it would have been more in compliance
with hexagonal architecture to make the division between cucumber
tests and aruba slightly different. Basically I think you could have
achieved the same results by simply write non-spawining step
definitions (Using CucumberProcess) for steps in features that are now
marked `~@spawn` and keep using aruba steps unmodified (as in release
0.5.1) for all the steps in features that are now marked `@spawn`.

To be honest I dislike the new complexity/flexibility introduced in
aruba 0.5.2 and I will argue that any project (including cucumber)
exploiting this new flexibility (setting Aruba.process =
CustomeProcess) would be better off writing custom steps in stead of
replacing arubas process class.

That way it would also be possible to combine non-spawning cucumber
steps and classic spawning aruba steps within the same feature test.

Is there anybody there that understand what I mean? Will it make a
difference if I show it on a branch?

Jarl


2013/4/19 Oleg Sukhodolsky <os9...@gmail.com>:

--
Jarl Friis
Softace ApS
Rådhustorvet 7, 2.
3520 Farum
LinkedIn: http://dk.linkedin.com/in/jarlfriis

[Oleg Sukhodolsky]

On Fri, Apr 19, 2013 at 10:30 PM, Jarl Friis <ja...@softace.dk> wrote:

It's  a fantatic speedup, great stuff.

I know I am far too late on this, sorry for that. I should have shared
my opinion on issue 148 (I thought I was watching the project; now I
do) and for that reason I expect no one will listen to me now, however
I still would like to comment (on the changes to aruba).

For the sake of Aruba, I think it would have been more in compliance
with hexagonal architecture to make the division between cucumber
tests and aruba slightly different. Basically I think you could have
achieved the same results by simply write non-spawining step
definitions (Using CucumberProcess) for steps in features that are now
marked `~@spawn` and keep using aruba steps unmodified (as in release
0.5.1) for all the steps in features that are now marked `@spawn`.

To be honest I dislike the new complexity/flexibility introduced in
aruba 0.5.2 and I will argue that any project (including cucumber)
exploiting this new flexibility (setting Aruba.process =
CustomeProcess) would be better off writing custom steps in stead of
replacing arubas process class.

That way it would also be possible to combine non-spawning cucumber
steps and classic spawning aruba steps within the same feature test.

Is there anybody there that understand what I mean? Will it make a
difference if I show it on a branch?

I think I do understand but real code would be better for sure :)

Oleg.

[Matt Wynne]

On 19 Apr 2013, at 20:04, Oleg Sukhodolsky <os9...@gmail.com> wrote:

On Fri, Apr 19, 2013 at 10:30 PM, Jarl Friis <ja...@softace.dk> wrote:

It's  a fantatic speedup, great stuff.

I know I am far too late on this, sorry for that. I should have shared
my opinion on issue 148 (I thought I was watching the project; now I
do) and for that reason I expect no one will listen to me now, however
I still would like to comment (on the changes to aruba).

For the sake of Aruba, I think it would have been more in compliance
with hexagonal architecture to make the division between cucumber
tests and aruba slightly different. Basically I think you could have
achieved the same results by simply write non-spawining step
definitions (Using CucumberProcess) for steps in features that are now
marked `~@spawn` and keep using aruba steps unmodified (as in release
0.5.1) for all the steps in features that are now marked `@spawn`.

To be honest I dislike the new complexity/flexibility introduced in
aruba 0.5.2 and I will argue that any project (including cucumber)
exploiting this new flexibility (setting Aruba.process =
CustomeProcess) would be better off writing custom steps in stead of
replacing arubas process class.

That way it would also be possible to combine non-spawning cucumber
steps and classic spawning aruba steps within the same feature test.

Is there anybody there that understand what I mean? Will it make a
difference if I show it on a branch?

I think I do understand but real code would be better for sure :)

I don't understand (I did try, because I can tell you are feeling concerned) and I would like to see some code too :)

cheers,

Matt

--
http://mattwynne.net || https://twitter.com/mattwynne || http://the-cucumber-book.com || http://bddkickstart.com || http://www.relishapp.com

[Jarl Friis]

I reconsidered my thoughts... My concern (for aruba) was from the
point of view that goal/intention/purpose of aruba was to "easily
*run* commands line utils from a cucumber feature". However reading
the headline of aruba README again it seems that purpose is to "make
it easier to *test* command line utils using cucumber".

With that purpose in mind I think it makes perfect sense with the
changes introduced in 0.5.2 because the new features are only useful
if you are *testing* a CLI util (written in ruby).

Jarl