Request for comments: Scenario

Testing RSpec
1

I created a gem a few weeks ago that I think the RSpec community might
be
interested in: GitHub - tysonmote/scenario: Basic spec scenarios for RSpec. (dormant) (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? :slight_smile:
2

On 4 June 2011 20:55, Tyson T. [email protected] wrote:

support too many different scenarios* non-approved user, regular user,
most of the bases, but please let me know if you have any questions. The
Francisco, CA 94110

This looks very elegant, a couple of points for feedback, having looked at
the 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

3

On Jun 4, 2011, at 2:55 PM, Tyson T. wrote:

I created a gem a few weeks ago that I think the RSpec community might be
interested in: GitHub - tysonmote/scenario: Basic spec scenarios for RSpec. (dormant) (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

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

The only difference that I see is the use of the term ‘scenario’, which
could be resolved with a couple of aliases.

WDYT?

David

4

On Sun, Jun 5, 2011 at 9:20 AM, David C.
[email protected]wrote:

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