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
