I coded something guys - https://github.com/paul-hammant/jbehave-core/commit/2195b7a4d5038d4f1f087c9f2fa7f92228430b3c- it works in a basic way. The flaw (when using it against a large commercial jbehave-webdriver solution) was that if the restart happened, a new browser frame was made. If someone else wants to finish it then go for it. Otherwise I'm giving up on it!!
- Paul On Mon, Jul 11, 2011 at 8:24 AM, Jonathan Woods < [email protected]> wrote: > 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] > phone: +1 612 229 6779 > > >
