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