[rspec-users] Reusing story snippets

Ben Mabey ben at benmabey.com
Tue Jun 17 18:38:18 EDT 2008

Jim Morris wrote:
> Hi, Not top posting (although I prefer it ;)
>> Cool. Are you talking directly through ruby constructs or through a
>> browser tool like selenium?
> I have a helper that makes posts and gets and deletes and puts
> directly to the server which is implements a mostly REST-ful API and
> written in Java.
> I use an Hpricot based matcher that implements have_xpath to test the
> XML that is returned for each API call.
> It is a true integration test that can test the server running locally
> or the staging server running at the Colo.
> I was using (and do use) Example groups for most of my integration
> tests, however I started using Programmatic Stories (not plain text
> stories) for a number of reasons.
> Firstly I prefer it looking like code so I put the whole thing in a
> single file...
> steps = Spec::Story::StepGroup.new do |define|
>   define.given("user has empty bag") do
> etc
> Story "test user can create, get and delete bags",...., :steps_for =>
> steps do
>   Scenario " create bag"...
>   Scenario "get bag..."
>   Scenario "delete bag..."
> etc
> I prefer this because I am a programmer, it keeps things in one place
> and makes it easy to maintain. I don't have stakeholders so plain text
> stories are just another layer for me. Although I would use them if I
> did have laymen stake holders. I am testing a REST-ful AJAX like API
> to a webservice, that is used by programmers, so my stakeholders would
> be/are programmers and again prefer programmatic code rather than
> plain text stories.
> The reason I like Stories in this case, rather than Examples, is that
> for integration testing, I can test all the edge cases for the API in
> the most DRY-full way. The steps are coded once and I can just define
> very thin Scenarios that test different parameters being passed in and
> exercise all those edge cases where parameters are bad or left out
> etc. Doing this the "old" way using Example groups was not at all DRY,
> but worked pretty well. (Although Example groups with tons of helpers
> maybe considered equivalent).
> The thing I have learned about all these BDD, TDD,  XP,  AGILE things
> is to be flexible and use the best tools and practices for the job.
> Being single minded and saying programmers can't use stories they are
> only for stake holders means we lose a good tool! (Not that I am
> accusing anyone of being single minded ;)
> Back to why I want/need these global setup/teardowns... And BDD
> purists stop reading now ;)
> When doing integration testing of a remote server this way you know
> all the tests need to have a login and a valid Sessionid in the
> cookie. You don't want to login/logoff every Scenario because it is
> SLOOOW. Logging in and out does not test the API other than the login
> and logoff API and that of course has been tested once already. It is
> not DRY to have to call login and logout in every Given, plus you need
> it to logout even if the tests fail. And lastly (Shudder) some tests
> have to rely on the state left by a previous test, hence the session
> id needs to be the same, for a group of scenarios like add a resource,
> modify the resource then delete the resource are best done as separate
> Scenarios, relying on the previous Scenario. It would be slow and not
> DRY to have to test add, then test add, modify, then test add, delete,
> it is better to have Scenario add, Scenario modify, Scenario delete. I
> know this flys in the face of SOP, but it is DRY and it is efficient
> (ie faster) and it works!
> I hope that explains where I am coming from and how I (Mis-)use these
> excellent tools you have written.
> Thanks
> Jim

Ahh, I forgot that the original post was not dealing with plain-text 
stories.  From what I understand now, you prefer the Given, When, Then 
language for your certain situation and want more flexibility to help 
DRY these programmer-only stories. That makes a lot more sense now that 
I'm reminded of the context, thanks.  :)

When testing all the different edge cases based on different parameters 
passed in the URL I find that nested describes (example groups), like 
you mentioned, provide a good way to DRY up specs.  The spec-docs also 
lend themselves well to readable docs for programmers wanting to use the 
API.  When using the story framework to do this are you suggesting that 
a story be able to have setup/teardown and also have specific 
setup/teardown for individual scenarios?  Or are you just suggesting 
setup/teardown for an entire story (and not the scenarios)?

That sounds reasonable and useful, so I hope I didn't come off sounding 
like I thought your idea was a poor one.  In the context of plaintext 
stories I was thinking it would be a dangerous way to go down unless the 
language helped the stakeholder.  Having more flexible setup/teardown 
for stories in general seems like a good idea that would help everyone 


More information about the rspec-users mailing list