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.
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
