Yes, that is definitely a problem for us. We are working with the Oracle BPM. The only way to access the process instances and its data is through web services. But it is not trivial for many reasons not worth to mention here. So, for now, the only interface to the application that we have is through its GUI.
In fact, we are on the eminence of buying a tool to facilitate the access to these resources (http://www.avioconsulting.com/services/solutions/atf) and we are right now evaluating how it would be without it. So, it's definitely difficult as you all could notice. Anyway, I have looked at the springsecurity example and clarified many points. Indeed, repeating the text of a step doesn't seems to be a great deal. Thanks all for your attention! Paulo Sérgio. On Tue, Sep 7, 2010 at 12:33 PM, Clemens Wyss <[email protected]> wrote: > > However, I'm not sure how you will be able to do > > a regession test as that assumes that the database starts in a > > known state. I would highly recommend looking at the setup > > of an environment that allows you access to > > all your resources > good points, +1 > > > ----- Ursprüngliche Nachricht ----- > > Von: Brian Repko > > Gesendet: 07.09.10 17:23 Uhr > > An: [email protected] > > Betreff: Re: [jbehave-user] Parametrizing stories > > > > Paulo, > > > > You may want to look at the Spring Security example in the > > JBehave 3 source code. > > It has just this - AuthenticationSteps, UserSteps, > > OrganizationSteps and a DbSteps > > in order to setup the database. > > > > You can use a technology like DbUnit in order to setup the data > > using JDBC. Its very > > easy and does not require more than a login with appropriate > > access. > > > > If you don't have that type of access and everything must be > > setup via the UI, then you > > will have to drive all setup via the UI. However, I'm not sure > > how you will be able to do > > a regession test as that assumes that the database starts in a > > known state. I would > > highly recommend looking at the setup of an environment that > > allows you access to > > all your resources (database, JMS queues, other systems) or > > allows you to access a > > "test double" (or "mock") version of that resource. For example, > > you could use hsqldb > > as your test database perhaps. > > > > Brian > > > > ----- Original message ----- > > From: "Paulo Sérgio Medeiros" <[email protected]> > > To: [email protected] > > Date: Tue, 7 Sep 2010 11:59:56 -0300 > > Subject: Re: [jbehave-user] Parametrizing stories > > > > Thanks for the answers, I'm just learning the process. > > > > Yes Cristiano, you really got the point, maybe I'm applying BDD > > with Use Case mind. :-) > > > > Ok, so in your view repeating the step description in many > > different scenarios/stories is not a problem, right? I'm still > > insisting on this point just to make sure that I'm not missing > > any part of how you do this. Repeating what Clements said: > > Say you > > have AuthenticationSteps, RegistrationSteps and ApprovalSteps the > > n I would implement @Given("I am authenticated as '<uid>' with > > password '<pw>'") in AuthenticationSteps (because it "fits" there > > ;-)) and re-use AuthenticationSteps (hence adding them to the > > InstanceStepsFactory call) in all three stories. > > In this case, the three stories would have "Given I am > > authenticated as '<uid>' with password '<pw>'" in their story > > files and I would add the AuthenticationSteps in > > the InstanceStepsFactory call to reuse its exectution. Is that > > the right way to do? > > --------------------- > > > > I have one last question. I have chosen the authentication > > example because it is very simple to understand. But in many > > applications, functionalities depends on the execution of > > another. How do you deal with this? For example, the > > request_approval story can only be executed if there is one > > registration request pending. Normally, we would do this by > > preparing the database state. But in my case, I'm not able to > > access the database. I have to do everything from the interface > > (selenium). GivenStories does make sense in this case? What are > > the other approaches? > > > > Best regards, > > Paulo Sergio. > > On Tue, Sep 7, 2010 at 8:32 AM, Cristiano Gavião > > <[1][email protected]> wrote: > > > > Hi Paulo, > > I agreed with Clemens... > > In my opinion, reusing things, the way you always do with OO, > > not always is a good thing when we start to think about User > > Stories. > > I had this kind of problem in my transition from UseCase to > > Stories. We had lots of use case diagrams in a tool and > > specification on ms word. > > The first thing that we learned was that we shouldn't write > > our story as it was a BASIC code with lots of GOTOs.(for > > people that remeber it ;-) )... BDD emerge from a User > > necessity to understand well the requirements... > > Other thing that I could observe is that a Uml Usecase Include > > doesn't fit well to a GivenStories... at least in our case, > > just feel ones was mantained... > > The we radically stopped to use UseCase as our capture > > requirements way, with it's Alternative " Users Crazyer" > > Paths, and we started to use Stories with scenarios and > > JBehave... > > Now we have Stories that has ONLY ONE main path and Scenarios > > that are variations inside the story context... it should be > > clear for our not technical user and for the team. User should > > read it, understand it, and sign it... > > We still use GivenStories, but only when we dont need any > > variations on the included story... > > Ok... not reusing texts maybe let us with more texts files... > > may be, but this texts could be at source control or on a wiki > > (being edited by the user himself) where we can easy track > > changes... > > And you have lots of way of reusing your Steps classes and > > others Java classes using the Jbehave DI feature... It's very > > powerfull.... > > cheers > > Cristiano > > Clemens Wyss escreveu: > > > > > > (in other words, the > > step description would be repeated in many different stories). > > > > why repeat? Say you have AuthenticationSteps > > RegistrationSteps > > and > > ApprovalSteps > > then I would implement Given("I am authenticated as '<uid>' > > with password '<pw>'") in AuthenticationSteps (because it > > "fits" there ;-) ) and re-use AuthenticationSteps (hence > > adding them to the InstanceStepsFactory call) in all three > > stories. Hope this makes my point clear? > > > > I was wondering if it would make sense to pass parameters in > > the > > GivenStories inclusion. > > > > Where should the parameters by applied? > > - GivenStories implies that you can specifiy multiple stories > > - what if the story has different scenarios? > > > > ----- Ursprüngliche Nachricht ----- > > Von: Paulo Sérgio Medeiros > > Gesendet: 07.09.10 07:51 Uhr > > An: [2][email protected] > > Betreff: Re: [jbehave-user] Parametrizing stories > > So, if I understood you correctly you are basically saying > > that I should not > > use the GivenStories functionality in this case and reuse the > > authentication > > steps code but not the authentication story description (in > > other words, the > > step description would be repeated in many different stories). > > Have I understood it correctly? > > I was wondering if it would make sense to pass parameters in > > the > > GivenStories inclusion. What do you think? > > On Tue, Sep 7, 2010 at 2:40 AM, Clemens Wyss > > <[3][email protected]> wrote: > > > > I would keep your authentication story (with its examples I > > guess?) as is > > and create a convenience Given-step à la: > > Given I am authenticated as '<uid>' with password '<pw>' > > for request registration and request approval stories. Code > > reuse can be > > made in the step implementation of Given("I am authenticated > > as '<uid>' with > > password '<pw>'") from which you can call the method(s) of the > > authentication story. You could (possibly should) implement > > this convenience > > step in the AuthenticationSteps class and include it in the > > registration and > > request approval stories. > > Regards > > Clemens > > > > ----- Ursprüngliche Nachricht ----- > > Von: Paulo Sérgio Medeiros > > Gesendet: 06.09.10 22:01 Uhr > > An: [4][email protected] > > Betreff: [jbehave-user] Parametrizing stories > > Hi, > > I'm testing an workflow application where many stories are > > dependent on > > others. > > Thus, there are many cases where two stories depend on the > > same story but > > with different parameters. > > One very simple example is the stories that depend on the > > login story. > > > > The > > > > following case illustrate the scenario: > > request_registration() -> authentication(user1,pass1) > > request_approval() -> authentication(manager1,pass2) > > '->' represents the dependency relationship between stories > > and the > > parenthesis represent the parameters passed from one story to > > another. > > So, in the example above, the story request_registration > > depends on the > > authentication story passing two parameters (a user and his > > password). > > > > Note > > > > that the request_approval story also depends on the > > authentication story, > > but with different parameters. > > Does any one have this same need? Does jbehave already > > implements > > > > something > > > > that can be used to get this behavior? > > Thanks! > > Paulo Sérgio. > > > > -------------------------------------------------------------- > > ------- > > To unsubscribe from this list, please visit: > > [5]http://xircles.codehaus.org/manage_email > > > > -------------------------------------------------------------- > > ------- > > To unsubscribe from this list, please visit: > > [6]http://xircles.codehaus.org/manage_email > > > > ----------------------------------------------------------------- > > ---- > > To unsubscribe from this list, please visit: > > [7]http://xircles.codehaus.org/manage_email > > > > References > > > > 1. mailto:[email protected] > > 2. mailto:[email protected] > > 3. mailto:[email protected] > > 4. mailto:[email protected] > > 5. http://xircles.codehaus.org/manage_email > > 6. http://xircles.codehaus.org/manage_email > > 7. http://xircles.codehaus.org/manage_email > > --- > > Brian Repko > > LearnThinkCode, Inc. > > email: [email protected] > > phone: +1 612 229 6779 > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
