My tuppence-worth: I think Brian's locks would be a more expressive way
of guaranteeing what you want - you need exclusive access to
the-shared-state-which-is-inventory. This would be usefulf for other
scenarios too, I imagine. Checking for itemUnavailable() might give
false positives - e.g. it might be unavailable for any number of
reasons, maybe because your application logic is faulty (e.g. the item
always was unavailable and shouldn't have been buyable in the first
place). That's always going to be a possibility with ad hoc allowances
like this, and working out why a test is failing will be made that much
more difficult. I don't know what other facilities JBehave is opening
up for restarting tests, but it feels like a dodgy path to go down.
And of course the failing test shows something real - that it really is
possible for a third party to purchase something between you choosing it
and checking out - and is therefore something which needs its own test/fix.
Jon
On 11/07/2011 00:14, Brian Repko wrote:
Paul,
Sorry for the late reply and the funky email format - I was on holiday and
deleted the original...
Been thinking about this and you may have to create a list of resource
locks
that be designated for each story. Story A needs product 1, 2 and 3
locked.
Story B needs the shopping cart locked. A BeforeStory or BeforeScenario
would then attempt to aquire all the locks (in the same order to avoid
deadlocks
and best designed in the most-used-resource-first order so as to fail
fast).
And an AfterStory/Scenario that releases the locks (on success or
failure).
These resource designations could be used for the parallel queue
assignment
as well so that those really really common resources are
single-threaded in
your test suite execution.
So, the real question then becomes - what to do when a lock request fails.
The JIRA raised is to requeue the story/scenario (can this be at the
scenario
level?) - which is a totally valid option - as well as wait /
notification collaboration -
which is difficult as different sets of tests will want different
types of wait / notification
algorithms. The last option is a spin-lock type of thing (sleep a
random number of
milliseconds and re-try the lock aquisition).
The other thing that can occur is that your test suite never completes
as you
keep requeueing - at some point you will have to fail on a requeue as
well.
There is a part of me that wonders if some of the Scala/Akka actor
stuff might
also apply here but that is just throwing something wild out there.
In the end, my thoughts were around lock acquisition and the ability
to define
a resource/lock model that matches your application/system and then
standard
parallel processing stuff around those locks.
Hope that helps - let me know if that's not clear.
Brian
---- original message ---
I've an app that takes seconds to go through a number of pages
(web-selenium) and get to a place where it uses a credit card to complete a
booking. Because I have several threads concurrently running stories, I'm
likely to encounter a situation where inventory has been depleted AFTER the
item has been placed in the cart. This is hard to cater for. What I really
want to do is start the booking again.
It would be a huge amount of state-modelelling and calling steps logic
outside of a steps invocation sequence ....
OR
... it would be simple to throw a recognized JBehave exception to restart
the scenario (or example table entry) if so desired.
if (page.hasItemUnavailableMessage()) {
throw new RestartScenarioException();
}
Thoughts?
- Paul
---
Brian Repko
LearnThinkCode, Inc. <http://www.learnthinkcode.com>
email: [email protected]
<mailto:[email protected]>
phone: +1 612 229 6779
