rspec users - Mar 2011 - given-when-then-and syntax support in Rspec

Hi David and fellows,

I know this subject has already been discussed here and there are 
already some attempts to support the given-when-then-and syntax in 
Rspec, like the links below:

https://gist.github.com/206969
https://github.com/jimweirich/rspec-given

First, I don''t understand the reason to adopt the capital method names 
Given/When/Then/And instead of given/when/then/and. Then, I don''t think
we can call this some real support for that syntax because "example"
is
not meant to be executed in any special order in Rspec nor it can be 
defined that any additional "then/and" should be aborted if a prior 
expectation wasn''t met. And both solutions seem to work by simple 
aliasing "example" and "describe".

I never used Cucumber because I find that working with it is cumbersome 
for most cases.

I''ve been working mostly with Grails on my daily job for about 2 years 
now since I moved to my current job. I wanted something like Rspec for 
Groovy and Grails and while searching for some alternative, I found EasyB:

http://www.easyb.org/

Actually I liked the story syntax they provide as well as the reports 
and I found it would be useful for Rspec to incorporate that style too:

http://www.easyb.org/howtos.html

What do you think?

Best regards!

Rodrigo.

On Mar 26, 2011, at 9:43 PM, Rodrigo Rosenfeld Rosas wrote:
> Hi David and fellows,
> 
> I know this subject has already been discussed here and there are already
some attempts to support the given-when-then-and syntax in Rspec, like the links
below:
> 
> https://gist.github.com/206969
> https://github.com/jimweirich/rspec-given
> 
> First, I don''t understand the reason to adopt the capital method
names Given/When/Then/And instead of given/when/then/and.
''when'', ''then'', and ''and''
are all Ruby keywords. You can define them as methods, but unpleasant things
happen.
> Then, I don''t think we can call this some real support for that
syntax because "example" is not meant to be executed in any special
order in Rspec nor it can be defined that any additional "then/and"
should be aborted if a prior expectation wasn''t met. And both solutions
seem to work by simple aliasing "example" and "describe".
> 
> I never used Cucumber because I find that working with it is cumbersome for
most cases.
> 
> I''ve been working mostly with Grails on my daily job for about 2
years now since I moved to my current job. I wanted something like Rspec for
Groovy and Grails and while searching for some alternative, I found EasyB:
> 
> http://www.easyb.org/
> 
> Actually I liked the story syntax they provide as well as the reports and I
found it would be useful for Rspec to incorporate that style too:
> 
> http://www.easyb.org/howtos.html
> 
> What do you think?
Adding first class support for feature/scenario/given/when/then would be a
fundamental change to rspec-core, requiring much more than simply exposing new
syntax. We''d need new formatters, new ways to define shared code, new
command line options, etc, etc. I think this would require too much work, and
make the libraries more complicated to use and maintain.

I like the direction that rspec-given takes us: an extension library on top of
RSpec. As you point out, it could be made more valuable by adding rich concepts
like "steps" that are different from "examples", but I think
that could be done within the context of rspec-given (or any other extension),
and I''d gladly consider adding new extension points that would make
that job easier.

Cheers,
David
> Best regards!
> 
> Rodrigo.

On 27 Mar 2011, at 03:43, Rodrigo Rosenfeld Rosas wrote:
> Hi David and fellows,
> 
> I know this subject has already been discussed here and there are already
some attempts to support the given-when-then-and syntax in Rspec, like the links
below:
> 
> https://gist.github.com/206969
> https://github.com/jimweirich/rspec-given
> 
> First, I don''t understand the reason to adopt the capital method
names Given/When/Then/And instead of given/when/then/and. Then, I don''t
think we can call this some real support for that syntax because
"example" is not meant to be executed in any special order in Rspec
nor it can be defined that any additional "then/and" should be aborted
if a prior expectation wasn''t met. And both solutions seem to work by
simple aliasing "example" and "describe".
> 
> I never used Cucumber because I find that working with it is cumbersome for
most cases.
> 
> I''ve been working mostly with Grails on my daily job for about 2
years now since I moved to my current job. I wanted something like Rspec for
Groovy and Grails and while searching for some alternative, I found EasyB:
> 
> http://www.easyb.org/
> 
> Actually I liked the story syntax they provide as well as the reports and I
found it would be useful for Rspec to incorporate that style too:
> 
> http://www.easyb.org/howtos.html
> 
> What do you think?
Why not just use Cucumber?
> 
> Best regards!
> 
> Rodrigo.
> 
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
cheers,
Matt

matt at mattwynne.net
07974 430184

Em 27-03-2011 06:55, David Chelimsky escreveu:
> On Mar 26, 2011, at 9:43 PM, Rodrigo Rosenfeld Rosas wrote:
>
>> Hi David and fellows,
>>
>> I know this subject has already been discussed here and there are
already some attempts to support the given-when-then-and syntax in Rspec, like
the links below:
>>
>> https://gist.github.com/206969
>> https://github.com/jimweirich/rspec-given
>>
>> First, I don''t understand the reason to adopt the capital
method names Given/When/Then/And instead of given/when/then/and.
> ''when'', ''then'', and
''and'' are all Ruby keywords. You can define them as methods,
but unpleasant things happen.
Right! Of course there was a reason! How didn''t I think about this 
before?! :)
>> Then, I don''t think we can call this some real support for
that syntax because "example" is not meant to be executed in any
special order in Rspec nor it can be defined that any additional
"then/and" should be aborted if a prior expectation wasn''t
met. And both solutions seem to work by simple aliasing "example" and
"describe".
>>
>> I never used Cucumber because I find that working with it is cumbersome
for most cases.
>>
>> I''ve been working mostly with Grails on my daily job for about
2 years now since I moved to my current job. I wanted something like Rspec for
Groovy and Grails and while searching for some alternative, I found EasyB:
>>
>> http://www.easyb.org/
>>
>> Actually I liked the story syntax they provide as well as the reports
and I found it would be useful for Rspec to incorporate that style too:
>>
>> http://www.easyb.org/howtos.html
>>
>> What do you think?
> Adding first class support for feature/scenario/given/when/then would be a
fundamental change to rspec-core, requiring much more than simply exposing new
syntax. We''d need new formatters, new ways to define shared code, new
command line options, etc, etc. I think this would require too much work, and
make the libraries more complicated to use and maintain.
I really don''t intend to replace current Rspec syntax. I like it too. I
just proposed to add these new syntax because I feel it is very useful, 
both for avoiding several expectations by example when you need 
something sequential and for generating good reports for some use cases.

I said that because I don''t agree that the library would be more 
complicated to use, although it would certainly add more maintainance 
work. It would just add some new syntax if the user wants it. For 
instance, we could do like EasyB does. Suggest creating .spec and .story 
files. Each one of them would use one of the approaches. That way, it 
wouldn''t make it more complicate to use. But I agree that maintainance 
would be harder, but on the other hand the user experience could improve 
a lot for some users.
> I like the direction that rspec-given takes us: an extension library on top
of RSpec. As you point out, it could be made more valuable by adding rich
concepts like "steps" that are different from "examples",
but I think that could be done within the context of rspec-given (or any other
extension), and I''d gladly consider adding new extension points that
would make that job easier.
Right, that''s awesome and I agree with you. But as it happens with 
rspec-rails, I think that rspec-given could be some official module to 
Rspec to show users that Rspec is commited to support this syntax too. 
The documentation could be integrated as well as it also happens to 
rspec-rails.

How do you see this possibility?

Best regards,

Rodrigo.

Em 27-03-2011 10:32, Matt Wynne escreveu:
> On 27 Mar 2011, at 03:43, Rodrigo Rosenfeld Rosas wrote:
>
>> Hi David and fellows,
>>
>> I know this subject has already been discussed here and there are
already some attempts to support the given-when-then-and syntax in Rspec, like
the links below:
>>
>> https://gist.github.com/206969
>> https://github.com/jimweirich/rspec-given
>>
>> First, I don''t understand the reason to adopt the capital
method names Given/When/Then/And instead of given/when/then/and. Then, I
don''t think we can call this some real support for that syntax because
"example" is not meant to be executed in any special order in Rspec
nor it can be defined that any additional "then/and" should be aborted
if a prior expectation wasn''t met. And both solutions seem to work by
simple aliasing "example" and "describe".
>>
>> I never used Cucumber because I find that working with it is cumbersome
for most cases.
>>
>> I''ve been working mostly with Grails on my daily job for about
2 years now since I moved to my current job. I wanted something like Rspec for
Groovy and Grails and while searching for some alternative, I found EasyB:
>>
>> http://www.easyb.org/
>>
>> Actually I liked the story syntax they provide as well as the reports
and I found it would be useful for Rspec to incorporate that style too:
>>
>> http://www.easyb.org/howtos.html
>>
>> What do you think?
> Why not just use Cucumber?
I''ll repeat myself: "I never used Cucumber because I find that
working
with it is cumbersome for most cases".

That is really the reason :) I don''t feel the need for the extra work.
I
just want to use directly the syntax in the test code. Writing step 
definitions besides the feature text seems too much work to me, while I 
would like to do both at once, even if I don''t get some english-only
(or
any other language) specification.

Regards,

Rodrigo

On Sun, Mar 27, 2011 at 11:16 PM, Rodrigo Rosenfeld Rosas
<lbocseg at yahoo.com.br> wrote:
> Em 27-03-2011 10:32, Matt Wynne escreveu:
>>
>> On 27 Mar 2011, at 03:43, Rodrigo Rosenfeld Rosas wrote:
>>
>>> Hi David and fellows,
>>>
>>> I know this subject has already been discussed here and there are
already
>>> some attempts to support the given-when-then-and syntax in Rspec,
like the
>>> links below:
>>>
>>> https://gist.github.com/206969
>>> https://github.com/jimweirich/rspec-given
>>>
>>> First, I don''t understand the reason to adopt the capital
method names
>>> Given/When/Then/And instead of given/when/then/and. Then, I
don''t think we
>>> can call this some real support for that syntax because
"example" is not
>>> meant to be executed in any special order in Rspec nor it can be
defined
>>> that any additional "then/and" should be aborted if a
prior expectation
>>> wasn''t met. And both solutions seem to work by simple
aliasing "example" and
>>> "describe".
>>>
>>> I never used Cucumber because I find that working with it is
cumbersome
>>> for most cases.
>>>
>>> I''ve been working mostly with Grails on my daily job for
about 2 years
>>> now since I moved to my current job. I wanted something like Rspec
for
>>> Groovy and Grails and while searching for some alternative, I found
EasyB:
>>>
>>> http://www.easyb.org/
>>>
>>> Actually I liked the story syntax they provide as well as the
reports and
>>> I found it would be useful for Rspec to incorporate that style too:
>>>
>>> http://www.easyb.org/howtos.html
>>>
>>> What do you think?
>>
>> Why not just use Cucumber?
>
> I''ll repeat myself: "I never used Cucumber because I find
that working with
> it is cumbersome for most cases".
>
Have you tried Steak? https://github.com/cavalle/steak

Aslak
> That is really the reason :) I don''t feel the need for the extra
work. I
> just want to use directly the syntax in the test code. Writing step
> definitions besides the feature text seems too much work to me, while I
> would like to do both at once, even if I don''t get some
english-only (or any
> other language) specification.
>
> Regards,
>
> Rodrigo
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Mar 27, 2011, at 5:12 PM, Rodrigo Rosenfeld Rosas wrote:
> Em 27-03-2011 06:55, David Chelimsky escreveu:
>> On Mar 26, 2011, at 9:43 PM, Rodrigo Rosenfeld Rosas wrote:
>> 
>>> Hi David and fellows,
>>> 
>>> I know this subject has already been discussed here and there are
already some attempts to support the given-when-then-and syntax in Rspec, like
the links below:
>>> 
>>> https://gist.github.com/206969
>>> https://github.com/jimweirich/rspec-given
>>> 
>>> First, I don''t understand the reason to adopt the capital
method names Given/When/Then/And instead of given/when/then/and.
>> ''when'', ''then'', and
''and'' are all Ruby keywords. You can define them as methods,
but unpleasant things happen.
> 
> Right! Of course there was a reason! How didn''t I think about this
before?! :)
> 
>>> Then, I don''t think we can call this some real support for
that syntax because "example" is not meant to be executed in any
special order in Rspec nor it can be defined that any additional
"then/and" should be aborted if a prior expectation wasn''t
met. And both solutions seem to work by simple aliasing "example" and
"describe".
>>> 
>>> I never used Cucumber because I find that working with it is
cumbersome for most cases.
>>> 
>>> I''ve been working mostly with Grails on my daily job for
about 2 years now since I moved to my current job. I wanted something like Rspec
for Groovy and Grails and while searching for some alternative, I found EasyB:
>>> 
>>> http://www.easyb.org/
>>> 
>>> Actually I liked the story syntax they provide as well as the
reports and I found it would be useful for Rspec to incorporate that style too:
>>> 
>>> http://www.easyb.org/howtos.html
>>> 
>>> What do you think?
>> Adding first class support for feature/scenario/given/when/then would
be a fundamental change to rspec-core, requiring much more than simply exposing
new syntax. We''d need new formatters, new ways to define shared code,
new command line options, etc, etc. I think this would require too much work,
and make the libraries more complicated to use and maintain.
> 
> I really don''t intend to replace current Rspec syntax. I like it
too. I just proposed to add these new syntax because I feel it is very useful,
both for avoiding several expectations by example when you need something
sequential and for generating good reports for some use cases.
> 
> I said that because I don''t agree that the library would be more
complicated to use
Then we disagree.
> although it would certainly add more maintainance work. It would just add
some new syntax if the user wants it. For instance, we could do like EasyB does.
Suggest creating .spec and .story files. Each one of them would use one of the
approaches. That way, it wouldn''t make it more complicate to use. But I
agree that maintainance would be harder, but on the other hand the user
experience could improve a lot for some users.
> 
>> I like the direction that rspec-given takes us: an extension library on
top of RSpec. As you point out, it could be made more valuable by adding rich
concepts like "steps" that are different from "examples",
but I think that could be done within the context of rspec-given (or any other
extension), and I''d gladly consider adding new extension points that
would make that job easier.
> 
> Right, that''s awesome and I agree with you. But as it happens with
rspec-rails, I think that rspec-given could be some official module to Rspec to
show users that Rspec is commited to support this syntax too.
Except that RSpec is _not_ committed to supporting this syntax.
> The documentation could be integrated as well as it also happens to
rspec-rails.
> 
> How do you see this possibility?
I appreciate your enthusiasm for this, and encourage you to write an extension
library that provides what you''re looking for, but I don''t
envision this getting merged into RSpec proper for the foreseeable future.

Cheers,
David

Em 28-03-2011 01:10, David Chelimsky escreveu:
> On Mar 27, 2011, at 5:12 PM, Rodrigo Rosenfeld Rosas wrote:
>
>> Em 27-03-2011 06:55, David Chelimsky escreveu:
>>> On Mar 26, 2011, at 9:43 PM, Rodrigo Rosenfeld Rosas wrote:
>>>
>>>> Hi David and fellows,
>>>>
>>>> I know this subject has already been discussed here and there
are already some attempts to support the given-when-then-and syntax in Rspec,
like the links below:
>>>>
>>>> https://gist.github.com/206969
>>>> https://github.com/jimweirich/rspec-given
>>>>
>>>> First, I don''t understand the reason to adopt the
capital method names Given/When/Then/And instead of given/when/then/and.
>>> ''when'', ''then'', and
''and'' are all Ruby keywords. You can define them as methods,
but unpleasant things happen.
>> Right! Of course there was a reason! How didn''t I think about
this before?! :)
>>
>>>> Then, I don''t think we can call this some real support
for that syntax because "example" is not meant to be executed in any
special order in Rspec nor it can be defined that any additional
"then/and" should be aborted if a prior expectation wasn''t
met. And both solutions seem to work by simple aliasing "example" and
"describe".
>>>>
>>>> I never used Cucumber because I find that working with it is
cumbersome for most cases.
>>>>
>>>> I''ve been working mostly with Grails on my daily job
for about 2 years now since I moved to my current job. I wanted something like
Rspec for Groovy and Grails and while searching for some alternative, I found
EasyB:
>>>>
>>>> http://www.easyb.org/
>>>>
>>>> Actually I liked the story syntax they provide as well as the
reports and I found it would be useful for Rspec to incorporate that style too:
>>>>
>>>> http://www.easyb.org/howtos.html
>>>>
>>>> What do you think?
>>> Adding first class support for feature/scenario/given/when/then
would be a fundamental change to rspec-core, requiring much more than simply
exposing new syntax. We''d need new formatters, new ways to define
shared code, new command line options, etc, etc. I think this would require too
much work, and make the libraries more complicated to use and maintain.
>> I really don''t intend to replace current Rspec syntax. I like
it too. I just proposed to add these new syntax because I feel it is very
useful, both for avoiding several expectations by example when you need
something sequential and for generating good reports for some use cases.
>>
>> I said that because I don''t agree that the library would be
more complicated to use
> Then we disagree.
>
>> although it would certainly add more maintainance work. It would just
add some new syntax if the user wants it. For instance, we could do like EasyB
does. Suggest creating .spec and .story files. Each one of them would use one of
the approaches. That way, it wouldn''t make it more complicate to use.
But I agree that maintainance would be harder, but on the other hand the user
experience could improve a lot for some users.
>>
>>> I like the direction that rspec-given takes us: an extension
library on top of RSpec. As you point out, it could be made more valuable by
adding rich concepts like "steps" that are different from
"examples", but I think that could be done within the context of
rspec-given (or any other extension), and I''d gladly consider adding
new extension points that would make that job easier.
>> Right, that''s awesome and I agree with you. But as it happens
with rspec-rails, I think that rspec-given could be some official module to
Rspec to show users that Rspec is commited to support this syntax too.
> Except that RSpec is _not_ committed to supporting this syntax.
>
>> The documentation could be integrated as well as it also happens to
rspec-rails.
>>
>> How do you see this possibility?
> I appreciate your enthusiasm for this, and encourage you to write an
extension library that provides what you''re looking for, but I
don''t envision this getting merged into RSpec proper for the
foreseeable future.
Ok, thank you for your feedback :)

Rodrigo.