> 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
