I created a gem a few weeks ago that I think the RSpec community might be interested in: https://github.com/tysontate/scenario (and that I''d love to get feedback on). It supports RSpec 1 and 2. It aims to solve a few of the problems we''ve had with a large spec suite that''s been built over several years: - A veritable forest of global helper methods that often overlap in scope. Some of the method signatures on these methods are horrendous because people have tried to adapt, for example, a single "create_user" method to support too many different scenarios* ? non-approved user, regular user, admin user, and so on. - Expensive setup that doesn''t allow granular control over what, exactly, gets set up without adding more options to the helper method or creating another redundant setup method. - (This is the most important one.) Tons of redundant setup code. Throughout many large spec suites, you''ll notice a lot of redundant setup code. This redundant code can easily be grouped into a scenario that can more easily be reused throughout your specs. I''d love to hear any feedback you guys might have. The readme should cover most of the bases, but please let me know if you have any questions. The current examples in the readme are a bit trivial and don''t really make a strong case for the use of scenarios over mixins, but I''ll try to come up with better examples soon. -Tyson * See what I did there? :) -- *CrowdFlower <http://crowdflower.com/> @ *2111 Mission St, Suite 302, San Francisco, CA 94110 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20110604/d7b7a564/attachment.html>
On 4 June 2011 20:55, Tyson Tate <tyson at crowdflower.com> wrote:> I created a gem a few weeks ago that I think the RSpec community might be > interested in: https://github.com/tysontate/scenario (and that I''d love to > get feedback on). It supports RSpec 1 and 2. > > It aims to solve a few of the problems we''ve had with a large spec suite > that''s been built over several years: > > - A veritable forest of global helper methods that often overlap in > scope. Some of the method signatures on these methods are horrendous because > people have tried to adapt, for example, a single "create_user" method to > support too many different scenarios* ? non-approved user, regular user, > admin user, and so on. > - Expensive setup that doesn''t allow granular control over what, > exactly, gets set up without adding more options to the helper method or > creating another redundant setup method. > - (This is the most important one.) Tons of redundant setup code. > Throughout many large spec suites, you''ll notice a lot of redundant setup > code. This redundant code can easily be grouped into a scenario that can > more easily be reused throughout your specs. > > I''d love to hear any feedback you guys might have. The readme should cover > most of the bases, but please let me know if you have any questions. The > current examples in the readme are a bit trivial and don''t really make a > strong case for the use of scenarios over mixins, but I''ll try to come up > with better examples soon. > > -Tyson > > * See what I did there? :) > > -- > *CrowdFlower <http://crowdflower.com/> @ *2111 Mission St, Suite 302, San > Francisco, CA 94110 > > > This looks very elegant, a couple of points for feedback, having looked atthe github page. 1. No installation instructions 2. No specific instructions about how this works with rspec, e.g. do you have to do anything with spec_helper 3. No explanation of where files should be put (in spec folder?) 4. I think the fixtures section could be fleshed out a bit with an example HTH Andrew> _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- ------------------------ Andrew Premdas blog.andrew.premdas.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20110605/0ce8f304/attachment-0001.html>
On Jun 4, 2011, at 2:55 PM, Tyson Tate wrote:> I created a gem a few weeks ago that I think the RSpec community might be interested in: https://github.com/tysontate/scenario (and that I''d love to get feedback on). It supports RSpec 1 and 2. > > It aims to solve a few of the problems we''ve had with a large spec suite that''s been built over several years: > A veritable forest of global helper methods that often overlap in scope. Some of the method signatures on these methods are horrendous because people have tried to adapt, for example, a single "create_user" method to support too many different scenarios* ? non-approved user, regular user, admin user, and so on. > Expensive setup that doesn''t allow granular control over what, exactly, gets set up without adding more options to the helper method or creating another redundant setup method. > (This is the most important one.) Tons of redundant setup code. Throughout many large spec suites, you''ll notice a lot of redundant setup code. This redundant code can easily be grouped into a scenario that can more easily be reused throughout your specs. > I''d love to hear any feedback you guys might have. The readme should cover most of the bases, but please let me know if you have any questions. The current examples in the readme are a bit trivial and don''t really make a strong case for the use of scenarios over mixins, but I''ll try to come up with better examples soon. > > -TysonHey Tyson, I hate to be the bearer of "you can already do that", but, you can already do that (as of rspec-core-2.6) http://relishapp.com/rspec/rspec-core/dir/example-groups/shared-context https://gist.github.com/1009111 The only difference that I see is the use of the term ''scenario'', which could be resolved with a couple of aliases. WDYT? David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20110605/b1a9e5f4/attachment.html>
On Sun, Jun 5, 2011 at 9:20 AM, David Chelimsky <dchelimsky at gmail.com>wrote:> > Hey Tyson, > > I hate to be the bearer of "you can already do that", but, you can already > do that (as of rspec-core-2.6) > > http://relishapp.com/rspec/rspec-core/dir/example-groups/shared-context > https://gist.github.com/1009111 > > The only difference that I see is the use of the term ''scenario'', which > could be resolved with a couple of aliases. > > WDYT? >I''ve no idea how I missed that! I swear I looked through the docs to see if it was something I could already do. In any case, our main spec suite still runs under RSpec 1 (there''s a few dependencies keeping us from upgrading), so it''s still useful for us. The only other difference I can see is the "setup_for" sugar, but that''s something that could easily be added on top of shared_context. I''ll dig into that. Thanks for the tip! -Tyson -- *CrowdFlower <http://crowdflower.com/> @ *2111 Mission St, Suite 302, San Francisco, CA 94110 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20110605/7b389d5e/attachment.html>