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