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