[jbehave-user] Help getting the trader-runner-webdriver example

[Jorge Pombar]

First of all thanks for developing such a great, interesting and useful 
framework. I'm brand new to Maven so please bare with my very basic questions.
I'm having issues getting the trader-runner-webdriver from gitHub. I know that 
I'm probably missing something very basic.

Thanks in advance for your help.

Here is the pom.xml file I have:
http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>
  4.0.0
  com.mycompany.app
  my-app
  jar
  1.0-SNAPSHOT
  my-app
  http://maven.apache.org
  

  org.jbehave.web.examples
  jbehave-web-trader-webdriver
  3.6-SNAPSHOT

  
  

org.jbehave.web.examples

https://github.com/jbehave/jbehave-web/tree/master/examples

  


And here is the output/error I get from when running mvn install:
$ mvn install
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building my-app 1.0-SNAPSHOT
[INFO] 
Downloading: https://github.com/jbehave/jbehave-web/tree/master/examples/org/jbe
have/web/examples/jbehave-web-trader-webdriver/3.6-SNAPSHOT/maven-metadata.xml
Downloading: https://github.com/jbehave/jbehave-web/tree/master/examples/org/jbe
have/web/examples/jbehave-web-trader-webdriver/3.6-SNAPSHOT/jbehave-web-trader-w
ebdriver-3.6-SNAPSHOT.pom
[WARNING] The POM for org.jbehave.web.examples:jbehave-web-trader-webdriver:jar:
3.6-SNAPSHOT is missing, no dependency information available
Downloading: https://github.com/jbehave/jbehave-web/tree/master/examples/org/jbe
have/web/examples/jbehave-web-trader-webdriver/3.6-SNAPSHOT/jbehave-web-trader-w
ebdriver-3.6-SNAPSHOT.jar
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 3.532s
[INFO] Finished at: Thu May 03 11:48:14 PDT 2012
[INFO] Final Memory: 3M/15M
[INFO] 
[ERROR] Failed to execute goal on project my-app: Could not resolve dependencies
 for project com.mycompany.app:my-app:jar:1.0-SNAPSHOT: Could not find artifact
org.jbehave.web.examples:jbehave-web-trader-webdriver:jar:3.6-SNAPSHOT in org.jb
ehave.web.examples (https://github.com/jbehave/jbehave-web/tree/master/examples)
 -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyReso
lutionException

Thanks,
Enrique

RE: [jbehave-user] Help getting the trader-runner-webdriver example

[Jorge Pombar]

Thanks for pointing me in the right direction, now I have all the examples 
working. This is what I did (just in case it helps anyone else):

-  Checked out the jbehave-web codebase as pointed out below

-  Ran the mvn command (this produced errors when executing the test 
cases)

-  From eclipse (with m2e plugin), did a File->Import-> Existing Maven 
Projects and selected the root dir where I checked out the code. Now I was able 
to run TraderWebStories as a Junit

-  On the TraderWebStories contructor I had to add this line to make it 
work
  //required in case FF is not installed on the expected dir
System.setProperty("webdriver.firefox.bin", "E:\\Program Files\\Mozilla 
Firefox\\firefox.exe");

After this I was able to run the trader-webdriver examples successfully

Thanks,
Enrique

From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
Sent: Friday, May 04, 2012 3:11 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Help getting the trader-runner-webdriver example

Hi Jorge,

what are you trying to do?  The trader-runner-webdriver is not meant as a 
dependency you can declare.  It's a module that contains the stories run using 
the selenium webdriver API.

If you want to build the examples, checkout out the entire jbehave-web codebase 
https://github.com/jbehave/jbehave-web/tree/master and

mvn clean install -Pexamples

If you are looking to get started with Maven and webdriver, I suggest to use an 
archetype:

mvn archetype:generate -Dfilter=org.jbehave:jbehave

Choosing archetype 7 or 8.

More on using archetypes with JBehave:  
http://jbehave.org/reference/stable/archetypes.html

Cheers

On 03/05/2012 20:57, Jorge Pombar wrote:
First of all thanks for developing such a great, interesting and useful 
framework. I'm brand new to Maven so please bare with my very basic questions.
I'm having issues getting the trader-runner-webdriver from gitHub. I know that 
I'm probably missing something very basic.

Thanks in advance for your help.

Here is the pom.xml file I have:
http://maven.apache.org/POM/4.0.0";<http://maven.apache.org/POM/4.0.0> 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";<http://www.w3.org/2001/XMLSchema-instance>
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";<http://maven.apache.org/POM/4.0.0http:/maven.apache.org/maven-v4_0_0.xsd>>
  4.0.0
  com.mycompany.app
  my-app
  jar
  1.0-SNAPSHOT
  my-app
  http://maven.apache.org
  

  org.jbehave.web.examples
  jbehave-web-trader-webdriver
  3.6-SNAPSHOT

  
  

org.jbehave.web.examples

https://github.com/jbehave/jbehave-web/tree/master/examples

  


And here is the output/error I get from when running mvn install:
$ mvn install
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building my-app 1.0-SNAPSHOT
[INFO] 
Downloading: https://github.com/jbehave/jbehave-web/tree/master/examples/org/jbe
have/web/examples/jbehave-web-trader-webdriver/3.6-SNAPSHOT/maven-metadata.xml
Downloading: https://github.com/jbehave/jbehave-web/tree/master/examples/org/jbe
have/web/examples/jbehave-web-trader-webdriver/3.6-SNAPSHOT/jbehave-web-trader-w
ebdriver-3.6-SNAPSHOT.pom
[WARNING] The POM for org.jbehave.web.examples:jbehave-web-trader-webdriver:jar:
3.6-SNAPSHOT is missing, no dependency information available
Downloading: https://github.com/jbehave/jbehave-web/tree/master/examples/org/jbe
have/web/examples/jbehave-web-trader-webdriver/3.6-SNAPSHOT/jbehave-web-trader-w
ebdriver-3.6-SNAPSHOT.jar
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 3.532s
[INFO] Finished at: Thu May 03 11:48:14 PDT 2012
[INFO] Final Memory: 3M/15M
[INFO] 
[ERROR] Failed to execute goal on project my-app: Could not resolve dependencies
 for project com.mycompany.app:my-app:jar:1.0-SNAPSHOT: Could not find artifact
org.jbehave.web.examples:jbehave-web-trader-webdriver:jar:3.6-SNAPSHOT in org.jb
ehave.web.examples (https://github.com/jbehave/jbehave-web/tree/master/examples)
 -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyReso
lutionException

Thanks,
Enrique

[jbehave-user] Using GivenStories can I turn off execution of GivenStories ran using a Meta tag?

[Jorge Pombar]

I have all the stories of my project in a single folder "src/main/stories"
I'm building my test cases/stories in small blocks. So I test Story1 and then I 
test Story2 but it depends on Story1 to have been completed. So I'm using 
GivenStories:

-  Story1.story

-  Story2.story (uses GivenStories: Story1.story)

-  Story3.story (uses GivenStories: Story2.story)

I'm wondering if there is a way to add a meta tag on Story1 and Story2 that 
tells the framework not to run them because they will be run as part of 
Story3.story

Thanks for your help,
Enrique

RE: [jbehave-user] Using GivenStories can I turn off execution of GivenStories ran using a Meta tag?

[Jorge Pombar]

Currently I'm half way there. On the storyPaths() method instead of using the 
out of the box find paths:
return new 
StoryFinder().findPaths(codeLocationFromClass(this.getClass()).getFile(), 
asList("**/" + System.getProperty("storyFilter", "*") + ".story"), null);

I have a separate file that lists all the story files:
Story1.story
#Story2.story
Story3.story

Then I have a small parser that parses this file skipping any lines commented 
out (my choice was #) and returns me the List I can feed into findPaths method. 
My return statement now looks like
return new 
StoryFinder().findPaths(codeLocationFromClass(this.getClass()).getFile(), 
myStoryList, null);
where myStoryList was the list I populated with my parser

So now I don't run Story2.story (in this case) by itself. However, all the 
cases inside Story2.story still run when I run Story3.story (which is using 
GivenStories: Story2.story)

My question now is:
How can I set meta properties at the scenario level? Do you have sample code
How can I pass this to the GivenStories? Do you have sample code?

Thanks,
Enrique

From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
Sent: Tuesday, May 08, 2012 3:07 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Using GivenStories can I turn off execution of 
GivenStories ran using a Meta tag?

Hi,

no, this behaviour is not currently available.  GivenStories are recursively 
run.

What you could do is set meta properties at a scenario level which are passed 
to the given stories and then in your implementation take notice of these 
properties to run or not the relevant steps.

Otherwise, structure your given dependency tree in such a way as to avoid 
duplication.

Feel free to suggest a way to configure this behaviour you're after.

Cheers

On 08/05/2012 04:59, Jorge Pombar wrote:
I have all the stories of my project in a single folder "src/main/stories"
I'm building my test cases/stories in small blocks. So I test Story1 and then I 
test Story2 but it depends on Story1 to have been completed. So I'm using 
GivenStories:

-  Story1.story

-  Story2.story (uses GivenStories: Story1.story)

-  Story3.story (uses GivenStories: Story2.story)

I'm wondering if there is a way to add a meta tag on Story1 and Story2 that 
tells the framework not to run them because they will be run as part of 
Story3.story

Thanks for your help,
Enrique

RE: [jbehave-user] Announcement: Beta Release of new jbehave-junit-runner

[Jorge Pombar]

Thanks for the great feature as usual.
I’m having some issues integrating this into my code. Here is the stack trace 
I’m getting:
java.lang.NullPointerException: story not setup for CrossReference
at 
org.jbehave.core.reporters.CrossReference$XRefStepMonitor.stepMatchesPattern(CrossReference.java:228)
at 
org.jbehave.core.steps.DelegatingStepMonitor.stepMatchesPattern(DelegatingStepMonitor.java:25)
at 
org.jbehave.core.steps.StepCandidate.matches(StepCandidate.java:135)
at 
de.codecentric.jbehave.junit.monitoring.JUnitDescriptionGenerator.addSteps(JUnitDescriptionGenerator.java:97)
at 
de.codecentric.jbehave.junit.monitoring.JUnitDescriptionGenerator.addScenarioSteps(JUnitDescriptionGenerator.java:90)
at 
de.codecentric.jbehave.junit.monitoring.JUnitDescriptionGenerator.insertDescriptionForExamples(JUnitDescriptionGenerator.java:84)
at 
de.codecentric.jbehave.junit.monitoring.JUnitDescriptionGenerator.createDescriptionFrom(JUnitDescriptionGenerator.java:50)
at 
de.codecentric.jbehave.junit.monitoring.JUnitDescriptionGenerator.createDescriptionFrom(JUnitDescriptionGenerator.java:38)
at 
de.codecentric.jbehave.junit.monitoring.JUnitReportingRunner.buildDescriptionFromStories(JUnitReportingRunner.java:100)
at 
de.codecentric.jbehave.junit.monitoring.JUnitReportingRunner.(JUnitReportingRunner.java:57)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at 
org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
at 
org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.(JUnit4TestReference.java:33)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.(JUnit4TestClassReference.java:25)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Here is my config code:
@RunWith(JUnitReportingRunner.class)
public class AwesomeNameStories extends JUnitStories {

public AwesomeNameStories() {
CrossReference crossReference = new 
CrossReference().withJsonOnly().withOutputAfterEachStory(true)
.excludingStoriesWithNoExecutedScenarios(true);
ContextView contextView = new LocalFrameContextView().sized(640, 120);
SeleniumContext seleniumContext = new SeleniumContext();
SeleniumStepMonitor stepMonitor = new SeleniumStepMonitor(contextView, 
seleniumContext,
crossReference.getStepMonitor());
Format[] formats = new Format[] { new 
SeleniumContextOutput(seleniumContext), CONSOLE, WEB_DRIVER_HTML };
StoryReporterBuilder reporterBuilder = new StoryReporterBuilder()

.withCodeLocation(codeLocationFromClass(AwesomeNameStories.class)).withFailureTrace(true)

.withFailureTraceCompression(true).withDefaultFormats().withFormats(formats)
.withCrossReference(crossReference);

Configuration configuration = new 
SeleniumConfiguration().useSeleniumContext(seleniumContext)
.useFailureStrategy(new FailingUponPendingStep())
.useStoryControls(new 
StoryControls().doResetStateBeforeScenario(false)).useStepMonitor(stepMonitor)
.useStoryLoader(new LoadFromClasspath(AwesomeNameStories.class))
.useStoryReporterBuilder(reporterBuilder);
useConfiguration(configuration);

ApplicationContext context = new 
SpringApplicationContextFactory("vipmgr-steps.xml").createApplicationConte

[jbehave-user] Story level GivenStories

[Jorge Pombar]

>From my testing it seems like GivenStories can only be used at the Scenario 
>level and not at the Story level. Is this correct?

If so, I'm a little stuck on my use case. I'm testing a webApp and the first 
thing every Scenario need to do is log in. Hence I have a "baseLogin.story" 
that my scenarios use to log in. However, if I call this for every scenario it 
doesn't work because once you log in once if the session is still open the next 
time you are taken to the login page directly so the second scenario on the 
story fails when the GivenStory tries to execute for the second time.

I was hoping to be able to use "GivenStories" at the story level. In this case 
the GivenStory will execute only once at the beginning of any scenario and then 
all the scenarios in the story will execute.

I was also thinking that I have the option of logging out after every scenario 
(don't like because is very inefficient) or write code that detects if I'm 
logged in at the "baseLogin.story" level (seems bulky and wasteful). Is there a 
more elegant/proper way I'm missing?

Thanks in advance of the help,
Enrique

RE: [jbehave-user] Story level GivenStories

[Jorge Pombar]

Excellent, I would love for this feature to be added too. As Mauro said it 
would make the step visible and fully backwards compatible ☺

@Iulian
I didn’t want to implement it that way because it would make scenarios 
dependant on other scenarios. However, you did give me the idea of having a 
standalone scenario at the top that always runs and has the GivenStory 
baseLogin.story. This fixed my problem

Thanks everyone for the help!
Enrique

From: Iulian Greculescu [mailto:julian_grecule...@yahoo.com.au]
Sent: Thursday, June 28, 2012 3:26 PM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Story level GivenStories

>>having an optional GivenStories at story level as well as at scenario level
To me that would be a very good to have feature. Not necessarily you will 
always have GivenStories at both Story and Scenario level (you could if you 
needed it) but because you have the flexibility to choose which way is more 
appropiate for your concrete situation.

Cheers,

--- On Thu, 28/6/12, Mauro Talevi  wrote:

From: Mauro Talevi 
Subject: Re: [jbehave-user] Story level GivenStories
To: user@jbehave.codehaus.org
Received: Thursday, 28 June, 2012, 10:26 PM
@Before and @After annotations are useful for technical tasks but have the 
drawbacks of not being visible to the business (nor to the team, at least not 
as visible).

I think having an optional GivenStories at story level as well as at scenario 
level is possible and fully backward compatible.

On 28/06/2012 14:19, Andreas Ebbert-Karroum wrote:
Hi,

what about having a method annotated with @BeforeStories or @BeforeScenario?

Andreas
2012/6/28 Iulian Greculescu 
>
Hi Jorge,

I hope i understood your problem well.
Why don't u just say:

Scenario: User logs in and perform action A
Given Stories: baseLogin.story

Some action A steps

Scenario: Lodged on user can also perform action B

Some action B steps

and so on

I somehow had/have similar problems caused by the fact that is not quite easy 
to control what to run before all scenarios from that story (so before the 
story) and what do I need to run before each scenario. Such a feature would 
really be handy.

Cheers,
Julian


--- On Thu, 28/6/12, Mauro Talevi 
> wrote:

From: Mauro Talevi 
>
Subject: Re: [jbehave-user] Story level GivenStories
To: "user@jbehave.codehaus.org" 
>
Received: Thursday, 28 June, 2012, 5:32 PM

Hi,

You are right.  GivenStories apply to a scenario, but to satisfy your usecase 
you need only define a first scenario with your desired given story.
We can discuss the pros and cons of adding it to story level as standalone.

Cheers

On 28 Jun 2012, at 03:07, Jorge Pombar 
http://mc/compose?to=jorge_pom...@symantec.com>> 
wrote:

From my testing it seems like GivenStories can only be used at the Scenario 
level and not at the Story level. Is this correct?



If so, I’m a little stuck on my use case. I’m testing a webApp and the first 
thing every Scenario need to do is log in. Hence I have a “baseLogin.story” 
that my scenarios use to log in. However, if I call this for every scenario it 
doesn’t work because once you log in once if the session is still open the next 
time you are taken to the login page directly so the second scenario on the 
story fails when the GivenStory tries to execute for the second time.



I was hoping to be able to use “GivenStories” at the story level. In this case 
the GivenStory will execute only once at the beginning of any scenario and then 
all the scenarios in the story will execute.



I was also thinking that I have the option of logging out after every scenario 
(don’t like because is very inefficient) or write code that detects if I’m 
logged in at the “baseLogin.story” level (seems bulky and wasteful). Is there a 
more elegant/proper way I’m missing?



Thanks in advance of the help,

Enrique






--
Mit freundlichen Grüßen / Best regards

Andreas Ebbert-Karroum | Bereichsleiter der Agilen Software Factory

codecentric AG | Merscheider Straße 1 | 42699 Solingen | Deutschland
tel: +49 (0) 212.23362825 | fax: +49 (0) 212.23362879 | mobil: +49 (0) 
175.2664109
www.codecentric.de<http://www.codecentric.de> | 
blog.codecentric.de<http://blog.codecentric.de> | 
www.meettheexperts.de<http://www.meettheexperts.de> | 
www.more4fi.de<http://www.more4fi.de>

Sitz der Gesellschaft: Düsseldorf | HRB 63043
Vorstand: Klaus Jäger (Vorsitzender) | Mirko Novakovic . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Bernd Klinkmann . Jürgen Schütz

Diese E-Mail einschließlich evtl. beigefügter Dateien enthält vertrauliche 
und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige 
Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie 
bitte sofort den Absender und löschen Sie diese E-Mail und evtl. beigefügter 
Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder Öffnen evtl. beigefügter 
Dateien sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

[jbehave-user] @AfterScenario that runs only for certain story files/scenarios

[Jorge Pombar]

Hello, my use case is the following. I need to execute something at the end of 
90% of the scenarios but not for that 10%

If I use @AfterScenario that code runs after every single scenario. I was 
hoping that there was a way decide for which story the code annotated would 
run. By looking at the documentation I was hopeful when I saw the "uponType" 
condition. However, it seems like this is limited to NORMAL and EXAMPLE only.

Is there a way to extend this class and add my custom ScenarioTypes? If so, how 
do I tag a scenario with a type? Via meta tag?

In the mean time I'm just adding an extra step the end of the scenarios where I 
want the code to be executed. Is there a better way?

Thanks,
Enrique

RE: [jbehave-user] Story level GivenStories

[Jorge Pombar]

Hi Mauro,
I tested with the latest 3.7-SNAPSHOT 
(jbehave-core-3.7-20120629.105350-11.jar<https://nexus.codehaus.org/content/repositories/snapshots/org/jbehave/jbehave-core/3.7-SNAPSHOT/jbehave-core-3.7-20120629.105350-11.jar>)
 and it worked as advertized, thanks a lot ☺!
FYI, just make sure you have the “GivenStories” right after the Narrative 
(before it won’t work) and before any scenarios on the story

On a side note, is there an easy “Maven” way to use these snapshots? I manually 
copied the jar and replaced for the one I had in my local repository for 
testing. I was wondering if there is a better way. Thanks again for the fast 
feature!

Thanks,
Enrique

From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
Sent: Friday, June 29, 2012 3:18 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Story level GivenStories

Done - http://jira.codehaus.org/browse/JBEHAVE-792

A 3.7-SNAPSHOT has been published.  Can you please test with it before we 
proceed to release?

On 29/06/2012 02:10, Jorge Pombar wrote:
Excellent, I would love for this feature to be added too. As Mauro said it 
would make the step visible and fully backwards compatible ☺

@Iulian
I didn’t want to implement it that way because it would make scenarios 
dependant on other scenarios. However, you did give me the idea of having a 
standalone scenario at the top that always runs and has the GivenStory 
baseLogin.story. This fixed my problem

Thanks everyone for the help!
Enrique

From: Iulian Greculescu [mailto:julian_grecule...@yahoo.com.au]
Sent: Thursday, June 28, 2012 3:26 PM
To: user@jbehave.codehaus.org<mailto:user@jbehave.codehaus.org>
Subject: Re: [jbehave-user] Story level GivenStories

>>having an optional GivenStories at story level as well as at scenario level
To me that would be a very good to have feature. Not necessarily you will 
always have GivenStories at both Story and Scenario level (you could if you 
needed it) but because you have the flexibility to choose which way is more 
appropiate for your concrete situation.

Cheers,

--- On Thu, 28/6/12, Mauro Talevi 
<mailto:mauro.tal...@aquilonia.org> wrote:

From: Mauro Talevi 
<mailto:mauro.tal...@aquilonia.org>
Subject: Re: [jbehave-user] Story level GivenStories
To: user@jbehave.codehaus.org<mailto:user@jbehave.codehaus.org>
Received: Thursday, 28 June, 2012, 10:26 PM
@Before and @After annotations are useful for technical tasks but have the 
drawbacks of not being visible to the business (nor to the team, at least not 
as visible).

I think having an optional GivenStories at story level as well as at scenario 
level is possible and fully backward compatible.

On 28/06/2012 14:19, Andreas Ebbert-Karroum wrote:
Hi,

what about having a method annotated with @BeforeStories or @BeforeScenario?

Andreas
2012/6/28 Iulian Greculescu 
>
Hi Jorge,

I hope i understood your problem well.
Why don't u just say:

Scenario: User logs in and perform action A
Given Stories: baseLogin.story

Some action A steps

Scenario: Lodged on user can also perform action B

Some action B steps

and so on

I somehow had/have similar problems caused by the fact that is not quite easy 
to control what to run before all scenarios from that story (so before the 
story) and what do I need to run before each scenario. Such a feature would 
really be handy.

Cheers,
Julian


--- On Thu, 28/6/12, Mauro Talevi 
> wrote:

From: Mauro Talevi 
>
Subject: Re: [jbehave-user] Story level GivenStories
To: "user@jbehave.codehaus.org" 
>
Received: Thursday, 28 June, 2012, 5:32 PM

Hi,

You are right.  GivenStories apply to a scenario, but to satisfy your usecase 
you need only define a first scenario with your desired given story.
We can discuss the pros and cons of adding it to story level as standalone.

Cheers

On 28 Jun 2012, at 03:07, Jorge Pombar 
http://mc/compose?to=jorge_pom...@symantec.com>> 
wrote:

From my testing it seems like GivenStories can only be used at the Scenario 
level and not at the Story level. Is this correct?



If so, I’m a little stuck on my use case. I’m testing a webApp and the first 
thing every Scenario need to do is log in. Hence I have a “baseLogin.story” 
that my scenarios use to log in. However, if I call this for every scenario it 
doesn’t work because once you log in once if the session is still open the next 
time you are taken to the login page directly so the second scenario on the 
story fails when the GivenStory tries to execute for the second time.



I was hoping to be able to use “GivenStories” at the story level. In this case 
the GivenStory will execute only once at the beginning of any scenario and then 
all the scenarios in the story will execute.



I was also thinking that I have the option of logging out after every scenario 
(don’t like because is very inefficient) or write code that detects if I’m 
logged in at the “baseLogin.story” level (seems bulky and wasteful). Is there a 

[jbehave-user] WebDriverScreenshotOnFailure: setting screenshot location

[Jorge Pombar]

Hello, I'm setting a custom report location with StoryReporterBuilder
StoryReporterBuilder reporterBuilder = new 
StoryReporterBuilder()
  
.withCodeLocation(codeLocationFromClass(NavitasStories.class)).withFailureTrace(true)

.withFailureTraceCompression(true).withDefaultFormats().withFormats(formats)
.withCrossReference(crossReference).withRelativeDirectory("myCustomLocation");

This is working fine when generating all the reports. However, the reports 
aren't able to find the screenshots which are still saved under 
"target\jbehave\screenshots". I was looking at the code and it seems it gets 
this location from the call "reporterBuilder.outputDirectory()".

I was thinking to extend WebDriverScreenshotOnFailure and override the 
screenshotPath method. But before doing that is there a better configuration 
way to achieve this?

On a related note. The purpose of the custom location is to generate separate 
reports for each automation run (we want to keep each result so we can go back 
to them if we have/want to). The only thing that I don't like is to copy the 
resources every time to each output folder of each run. I guess I could copy 
them to a single location and change all the templates to get the resources 
from there but this seems tedious. Do you have any ideas of a better approach?

Thanks,
Enrique

[jbehave-user] Running My extended JUnitStories class with Maven

[Jorge Pombar]

Hello,
As usual let me start with a big thank you for developing such a great 
framework.

We started from the jbehave-web-spring-archetype. I have finally tinkered 
enough with the configs and are happy with the setup in our stories 
(NavitasStories) class that extends JUnitStories, we use this class as our 
"Embedder" and run it from Eclipse as a JUnit and everything works fine. Now 
I'm working on the POM to setup up the build and running from cmd line.

I see that you have the different maven  goals for running as described here 
(http://jbehave.org/reference/stable/maven-goals.html). What we want to do is 
run our stories (NavitasStories) class from command line using maven. We have 
beans define in our beans.xml file and other project specific settings defined 
on NavitasStories hence we don't want to run with the plain "Embedder" used by 
the goals.

For simplicity I tried doing this using a new project taken from the archetype 
so I'm trying to run EtsyDotComStories. I tried adding both config params 
 and  to the POM and got the same error 
of type incompatibility when casting. What I'm doing wrong? Do I need a new 
class just for this? I tried searching for examples but didn't find any

Added to : foo.EtsyDotComStories 
and foo.EtsyDotComStories
Error from Maven:

[ERROR] Failed to execute goal 
org.jbehave:jbehave-maven-plugin:3.6.2:run-stories-as-embeddables 
(embeddable-stories) on project sandbox-jbehave-web: A type incompatibility 
occured while executing 
org.jbehave:jbehave-maven-plugin:3.6.2:run-stories-as-embeddables: 
foo.EtsyDotComStories cannot be cast to org.jbehave.core.InjectableEmbedder

and

[ERROR] Failed to execute goal 
org.jbehave:jbehave-maven-plugin:3.6.2:run-stories-as-embeddables 
(embeddable-stories) on project sandbox-jbehave-web: A type incompatibility 
occured while executing 
org.jbehave:jbehave-maven-plugin:3.6.2:run-stories-as-embeddables: 
foo.EtsyDotComStories cannot be cast to org.jbehave.core.embedder.Embedder

Thanks,
Enrique

RE: [jbehave-user] Running My extended JUnitStories class with Maven

[Jorge Pombar]

That works just as expected. Thanks for the help!

Thanks,
Enrique

From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
Sent: Thursday, July 12, 2012 3:12 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Running My extended JUnitStories class with Maven

Hi Enrique,

the JUnitStories is an instance of Embeddable, which provides a facade to the 
Embedder:

http://jbehave.org/reference/stable/javadoc/core/org/jbehave/core/Embeddable.html

As outlined in the examples (and in the archetypes as well), the simplest way 
to run YourStories (which extends JUnitStories) is the maven goal 
run-stories-as-embeddables specifying in the  element the path to 
YourStories java class, e.g. **/YourStories.java.  A typical example is 
provided on http://jbehave.org/reference/stable/maven-goals.html.

In this usecase, you don't need to bother about the Embedder, it's something 
that's handled under the hood.

Cheers

PS:  thanks for your feedback and support.

On 12/07/2012 02:58, Jorge Pombar wrote:
Hello,
As usual let me start with a big thank you for developing such a great 
framework.

We started from the jbehave-web-spring-archetype. I have finally tinkered 
enough with the configs and are happy with the setup in our stories 
(NavitasStories) class that extends JUnitStories, we use this class as our 
"Embedder" and run it from Eclipse as a JUnit and everything works fine. Now 
I'm working on the POM to setup up the build and running from cmd line.

I see that you have the different maven  goals for running as described here 
(http://jbehave.org/reference/stable/maven-goals.html). What we want to do is 
run our stories (NavitasStories) class from command line using maven. We have 
beans define in our beans.xml file and other project specific settings defined 
on NavitasStories hence we don't want to run with the plain "Embedder" used by 
the goals.

For simplicity I tried doing this using a new project taken from the archetype 
so I'm trying to run EtsyDotComStories. I tried adding both config params 
 and  to the POM and got the same error 
of type incompatibility when casting. What I'm doing wrong? Do I need a new 
class just for this? I tried searching for examples but didn't find any

Added to : foo.EtsyDotComStories 
and foo.EtsyDotComStories
Error from Maven:

[ERROR] Failed to execute goal 
org.jbehave:jbehave-maven-plugin:3.6.2:run-stories-as-embeddables 
(embeddable-stories) on project sandbox-jbehave-web: A type incompatibility 
occured while executing 
org.jbehave:jbehave-maven-plugin:3.6.2:run-stories-as-embeddables: 
foo.EtsyDotComStories cannot be cast to org.jbehave.core.InjectableEmbedder

and

[ERROR] Failed to execute goal 
org.jbehave:jbehave-maven-plugin:3.6.2:run-stories-as-embeddables 
(embeddable-stories) on project sandbox-jbehave-web: A type incompatibility 
occured while executing 
org.jbehave:jbehave-maven-plugin:3.6.2:run-stories-as-embeddables: 
foo.EtsyDotComStories cannot be cast to org.jbehave.core.embedder.Embedder

Thanks,
Enrique

[jbehave-user] null displays for Scenario name on the LocalFrameContextView when embedderControls are used

[Jorge Pombar]

I'm not sure if this is an artifact or I'm not setting the configurations 
correctly
To reproduce:

-  Start from the jBehave-spring-archetype

-  Configure the Embedder I tried both setting it on the constructor. Ie

o   
configuredEmbedder().embedderControls().doGenerateViewAfterStories(true).doIgnoreFailureInStories(false).doIgnoreFailureInView(true).doVerboseFailures(true).useThreads(2).useStoryTimeoutInSecs(60);

-  and overriding configuredEmbedder method. Ie

o   @Override public Embedder configuredEmbedder() {

o   //this line has no problems

o   
super.configuredEmbedder().useMetaFilters(Arrays.asList("-theme"));

o  //this is the problem line 
super.configuredEmbedder().embedderControls().doGenerateViewAfterStories(true).doIgnoreFailureInStories(false).doIgnoreFailureInView(true).doVerboseFailures(true).useThreads(2).useStoryTimeoutInSecs(60);

o

o   return super.configuredEmbedder();

o   }

-  Either one will reproduce the issue. Notice that in the ContextView 
it shows "null" for the Scenario name. If you run the same stories without 
using embedderControls the name displays correctly

Let me know if you want me to open an jira issue

Thanks,
Enrique

RE: [jbehave-user] Re: use steps from multiple step definition class for a single story

[Jorge Pombar]

I don't have much to add since everyone already did a great job answering. I'll 
share our solution which is based on the jbehave-spring-archetype available.

We have a PageObject package (all of our PageObjects representing pages on our 
application go here). Here we also have a BasePage which extends 
org.jbehave.web.selenium.WebDriverPage (this page contains WebDriverProvider). 
All of our pagesObjects extend BasePage. This way none of our pages handle the 
WebDriverProvider, they all just have a call to the super ctor passing the 
WebDriverProvider and we get all of those WebDriver methods findElement, etc.

In this package we also have a PageFactory class which provided the entry point 
where we pass the WebDriverProvider we initialize on our spring beans.xml file.

We then have a Steps package which contains all of our steps logically combined 
in classes (for example LoginSteps.java). Here we also have a BaseSteps which 
contain some common steps and all steps extend this class. The constructor of 
this class uses PageFactory to return an instance of the relevant page object. 
For example, SignIn page

Finally we initialize all of the step classes at the beginning of our run since 
they are defined in out spring beans.xml file

Again, we just expanded on the jbehave-spring-archetype, so that's a great 
starting point

Thanks,
Enrique

-Original Message-
From: Alexander Lehmann [mailto:alexl...@gmail.com] 
Sent: Monday, August 06, 2012 10:25 AM
To: user@jbehave.codehaus.org
Subject: [jbehave-user] Re: use steps from multiple step definition class for a 
single story

The suggested way to implement web testing steps in to abstract from the 
actual web implementation and use steps classes and another set of 
classes called page classes, the examples on the reference guide 
describe how to do that 
http://jbehave.org/reference/web/stable/page-objects.html (WebDriver API)

The actual work is done inside the page classes that all inherit from a 
class called WebDriverPage, which provides the usual WebDriver methods 
like get from Selenium.

If you are constructing the objects yourself, you have to pass a 
WebDriverProvider between the classes, if you are using dependency 
injection (guice, spring), this will happen automatically. The whole 
thing has to be run in a single thread executor unless you use a per 
story web driver.

You can use steps classes (plain classes not inheriting from anything) 
using different page classes (inheriting from the WebDriverPage class), 
so you can organize your classes (plus if you have different step 
classes using the same page classes you can refactor step implementations)


On 04.08.2012 10:53, Roy de Kleijn wrote:
> I like to organize my steps in multiple class files. (because we have
> many steps in our application)
>
> Question is: how can we use the steps from multiple step definition
> classes to execute a single story.
>
> I use webdriver, I tried the following:
>
> BaseClass.java
> Instantiates the driver and opens the browser.
>
> LoginSteps.java inherit from BaseClass.java
> steps to login in application
>
> SearchSteps.java inherit from BaseClass.java
> Verify is elements is present.
> BUT here is my driver instance suddenly null.
>
> I think it has something to do with the way I execute my tests:
> @Override
> public InjectableStepsFactory stepsFactory() { return new
> InstanceStepsFactory(configuration(), new LoginSteps(), new
> searchPageSteps()); }
>
> Please tell what other information you need or what I have to do
> differently.
> Thanks
>



-
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email



-
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[jbehave-user] Get access to PostStoryStatisticsCollector

[Jorge Pombar]

Hello, I'm trying to get the count of how many "test cases" ran
testCases = scenarios x examples

I can see all of this info in the "...stats.html". Looks like the class 
PostStoryStatisticsCollector has this information. I'm wondering how can I get 
access (and where in the code/execution) to this class?

I'm I going the right way? Or is there a better way to achieve this?

Thanks,
Enrique

RE: [jbehave-user] Get access to PostStoryStatisticsCollector

[Jorge Pombar]

2 follow up questions:

-  How can I access the ReportsCount class. Some sample code would be 
great!

-  "We expose the Reports themselves...". Is the suggestion to write a 
script to parse "...stats.html" to get the stats required? I was thinking about 
doing that as a stop gap solution for now. I was hoping to do it as part of the 
JBehave execution so I can change the reports template slightly and add this 
info in them. Any sample code out there on how to accomplish this?

I would be great if you could add the scenarios x examples count to the 
ReportsCount. Seems to me like this would be the best long term solution.

Thanks,
Enrique

From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
Sent: Friday, August 10, 2012 1:35 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Get access to PostStoryStatisticsCollector

The reports stats are read in the TemplateableViewGenerator and encapsulated in 
the Report class.  But only the ReportsCount class is exposed for the moment.  
We expose the Reports themselves and you could get the stats required, or we 
could add the scenarios x examples count the the ReportsCount.

On 09/08/2012 23:36, Jorge Pombar wrote:
Hello, I'm trying to get the count of how many "test cases" ran
testCases = scenarios x examples

I can see all of this info in the "...stats.html". Looks like the class 
PostStoryStatisticsCollector has this information. I'm wondering how can I get 
access (and where in the code/execution) to this class?

I'm I going the right way? Or is there a better way to achieve this?

Thanks,
Enrique

RE: [jbehave-user] can't execute etsy-stories-java-spring

[Jorge Pombar]

I had the same issue. It was because my network's firewall was blocking access 
to all ports (except the specific open ones). You need to turn that off, open 
access to the port or try to run from a different (more open) environment

Thanks,
Enrique

From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
Sent: Friday, September 21, 2012 8:26 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] can't execute etsy-stories-java-spring

Could be the version of Firefox.  I've tested with a fresh install of FF 15.0.1 
and it works fine with:

Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+)
Maven home: C:\Applications\Apache\apache-maven-3.0.4\bin\..
Java version: 1.6.0_35, vendor: Sun Microsystems Inc.
Java home: C:\Applications\Java\jdk1.6.0_35\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

The problem may also be a conflict with a VPN if you're running one.

Also, you may want to pull latest version of jbehave-tutorial, as I've updated 
to latest core release.

Note that you'll get some failures in etsy_cart, but it's a genuine issue with 
the page content that's changed, not a connection issue.

Cheers

On 21/09/2012 15:52, Roy de Kleijn wrote:
Hi,

I just pulled the etsy-stories-java-spring project, but it seems that the tests 
can't be run.

I tried to do this:

clean install -DstoryFilter=etsy_cart

The execution is stuck (for 30 seconds) at the narrative:
Narrative:
In order to show the basic cart functionality
As a user
I want to add and remove items from the cart


after that it will continue with these messages:
org.jbehave.web.selenium.PerStoryWebDriverSteps.beforeStory() (FAILED)
(org.jbehave.core.failures.BeforeOrAfterFailed: Method beforeStory (annotated 
with @BeforeStory in class org.jbehave.web.selenium.PerStoryWebDriverSteps) 
failed: org.openqa.selenium.WebDriverException: Unable to bind to locking port 
7054 within 45000 ms
Build info: version: '2.25.0', revision: '17482', time: '2012-07-18 22:18:01'
System info: os.name: 'Windows 7', os.arch: 'amd64', os.version: '6.1', 
java.version: '1.6.0_33'
Driver info: driver.version: 
FirefoxWebDriverProvider$DoublyOverriddenFirefoxDriver)
Scenario: Item can be added to cart
org.jbehave.tutorials.etsy.steps.LifecycleSteps.emptyCart() (FAILED)
(org.jbehave.core.failures.BeforeOrAfterFailed: Method emptyCart (annotated 
with @BeforeScenario in class org.jbehave.tutorials.etsy.steps.LifecycleSteps) 
failed: 
org.jbehave.web.selenium.DelegatingWebDriverProvider$DelegateWebDriverNotFound: 
WebDriver has not been found for this thread.
Please verify you are using the correct WebDriverProvider, with the appropriate 
credentials if using remote access, e.g. to SauceLabs: -DSAUCE_USERNAME=xx 
-DSAUCE_ACCESS_KEY=xxx----xxx )
Given that the cart is empty (NOT PERFORMED)
!-- We don't care for which item is added to the cart


It's a bit strange, I just wan't to run the test in my local firefox instance 
and I'm not using sauce.
What do I need to change here?


Thanks in advance,
Roy

[jbehave-user] When will jbehave-core 3.8.0 be on Maven Central

[Jorge Pombar]

Hi guys,
Thanks as usual for the great project you guys run. We are currently stuck at 
version jbehave-core 3.6.8 (and web 3.5.4) because of the metaFilters bug 
(JBEHAVE-868). I took the latest 
3.8 SNAPSHOT and confirmed that this issue is fixed.

The problem is that on Maven Central I only see up to version 3.7.4. Do you 
know when will you push 3.8 to Maven Central?

Thanks,
Enrique

RE: [jbehave-user] When will jbehave-core 3.8.0 be on Maven Central

[Jorge Pombar]

Thanks for the quick reply Mauro. This might be more of a Maven question but I 
think it might be pertinent to other users
I found out why maven wasn't pulling the 3.8 jar from the repo. It is because 
our project is a jBehave-web project.

The latest version of jBehave-web is 3.5.5 and that depends on jBehave 3.7.4. 
Maven resolved this by download and using the core 3.7.4 jar and ignoring my 
setting on my POM of jBehave-core version 3.8. I don't think this can be 
resolved (since the users don't manage jBehave web's pom) until there is a new 
Web release that depends on core 3.8. Am I correct in this assumption?

One last maven question. On my local repo all the jbehave-core version 3.6 and 
below have the core jar AND the sources.jar, 3.7 and above only have the code 
jar and not the sources. I do see the sources.jar when I navigate to the maven 
repo on the browser. Do you know why maven stopped downloading them?

Thanks,
Enrique

From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
Sent: Wednesday, April 17, 2013 11:24 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] When will jbehave-core 3.8.0 be on Maven Central

Hi Jorge,

JBehave 3.7.5 and 3.8 are synched with Central.  E.g. : 
http://repo2.maven.org/maven2/org/jbehave/jbehave/3.8/

But for some reason they don't appear in http://search.maven.org/

I'll try to get to the reason, but for the time being, you can simply pull it 
from Central as you would normally.

Cheers

PS:   Thanks for your kind words - always appreciated :-)

On 17/04/2013 19:22, Jorge Pombar wrote:
Hi guys,
Thanks as usual for the great project you guys run. We are currently stuck at 
version jbehave-core 3.6.8 (and web 3.5.4) because of the metaFilters bug 
(JBEHAVE-868<https://jira.codehaus.org/browse/JBEHAVE-868>). I took the latest 
3.8 SNAPSHOT and confirmed that this issue is fixed.

The problem is that on Maven Central I only see up to version 3.7.4. Do you 
know when will you push 3.8 to Maven Central?

Thanks,
Enrique

RE: [jbehave-user] When will jbehave-core 3.8.0 be on Maven Central

[Jorge Pombar]

Thx a bunch Mauro, the dependendyManagement works like a charm. Adding that 
section of my POM here in case it helps someone

  
  3.8
  

  

  
org.jbehave
jbehave-core
3.8
  

  

Thanks,
Enrique

From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
Sent: Wednesday, April 17, 2013 1:52 PM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] When will jbehave-core 3.8.0 be on Maven Central

Hi,

these are indeed more Maven questions.The short answer is no, you don't 
need to wait for a new web release.

If you want to use the latest version of core with web, simple declare it in 
the  section of your pom.xml.  This will override the 
transitive dependency from web pom.xml.

Alternatively, you can explicitly exclude the transitive dependency on 
jbehave-core from the jbehave-web artifacts and re-add explicitly with the 
desired version.The  solution is more elegant, but 
less known and less used.

As for sources in the your local repo, these are not downloaded by default by 
Maven CLI.   Usually, they are downloaded by the IDE, e.g. Eclipse, either on 
demand or eagerly depending on the the configuration of the relevant plugin.  
If you're using m2e, check the preferences.

Cheers

On 17/04/2013 22:39, Jorge Pombar wrote:
Thanks for the quick reply Mauro. This might be more of a Maven question but I 
think it might be pertinent to other users
I found out why maven wasn't pulling the 3.8 jar from the repo. It is because 
our project is a jBehave-web project.

The latest version of jBehave-web is 3.5.5 and that depends on jBehave 3.7.4. 
Maven resolved this by download and using the core 3.7.4 jar and ignoring my 
setting on my POM of jBehave-core version 3.8. I don't think this can be 
resolved (since the users don't manage jBehave web's pom) until there is a new 
Web release that depends on core 3.8. Am I correct in this assumption?

One last maven question. On my local repo all the jbehave-core version 3.6 and 
below have the core jar AND the sources.jar, 3.7 and above only have the code 
jar and not the sources. I do see the sources.jar when I navigate to the maven 
repo on the browser. Do you know why maven stopped downloading them?

Thanks,
Enrique

From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
Sent: Wednesday, April 17, 2013 11:24 AM
To: user@jbehave.codehaus.org<mailto:user@jbehave.codehaus.org>
Subject: Re: [jbehave-user] When will jbehave-core 3.8.0 be on Maven Central

Hi Jorge,

JBehave 3.7.5 and 3.8 are synched with Central.  E.g. : 
http://repo2.maven.org/maven2/org/jbehave/jbehave/3.8/

But for some reason they don't appear in http://search.maven.org/

I'll try to get to the reason, but for the time being, you can simply pull it 
from Central as you would normally.

Cheers

PS:   Thanks for your kind words - always appreciated :-)

On 17/04/2013 19:22, Jorge Pombar wrote:
Hi guys,
Thanks as usual for the great project you guys run. We are currently stuck at 
version jbehave-core 3.6.8 (and web 3.5.4) because of the metaFilters bug 
(JBEHAVE-868<https://jira.codehaus.org/browse/JBEHAVE-868>). I took the latest 
3.8 SNAPSHOT and confirmed that this issue is fixed.

The problem is that on Maven Central I only see up to version 3.7.4. Do you 
know when will you push 3.8 to Maven Central?

Thanks,
Enrique

[jbehave-user] RE: Using composite steps

[Jorge Pombar]

Hi Karlsson,
Yes you are using parameterized steps/scenarios 
(http://jbehave.org/reference/stable/parametrised-scenarios.html)
Any time you use $param in a step that will be replaced with the actual word in 
your story (in this case Agatha)

Thanks,
Enrique

From: Karlsson Christian [mailto:christian.karls...@cag.se]
Sent: Monday, April 22, 2013 9:23 AM
To: user@jbehave.codehaus.org
Subject: [jbehave-user] Using composite steps

Hello

I'm trying to use composite steps in my scenarios. Right now I'm facing a 
situation I can't get to work and I wonder if I'm doing it wrong or if my use 
case is out of scope.
Reproducing steps:
@Given("user $userId logs on first")
@Composite(steps = {
"Given that user  has logged in",
"When the user logs out",
"When user Charlie has logged in",
   "When the user logs out",
"When user Dickens has logged in",
"When the user logs off,"
   "When  user has logged in",
"When the user logs off"})
public void logTest(@Named("userId")
String userId) throws Exception {
}

@Given("that user  has logged in")
@When("user $userId has logged in")
public void login(@Named("userId")
String userId) throws Exception {
}

Scenario: Test composite steps
Given user Agatha logs on first

I get user "Agatha"  as the userId in all my steps. Is that the intended 
behavior?

Regards,
Christian

Christian Karlsson
CAG Contactor AB
Adress: Jan Stenbecks Torg 17, SE-164 40 Kista
Mobil: +46 (0)706694527
Mail: christian.karlsson  cag.se
www.cag.se

RE: [jbehave-user] Re: Repeating scenarios

[Jorge Pombar]

My apologies to pick up this old thread. This is a features that we are really 
interested on.

My question is for Julian, how do you "pick up randomly the stories".

Once you have the stories, how do you tell JBehave to run them again? (we only 
feed the stories once at the beginning of executing and haven't found a way to 
refeeding them to JBehave)

How to do extract the errors from the log? Do you parse the log file? Or do you 
access the a log object, if so how you do that?

I'll update the issue you mention below Mauro once we get some focus with our 
requirements

Thanks,
Enrique

From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
Sent: Sunday, December 23, 2012 7:05 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Re: Repeating scenarios

Hi All,

just chiming in for some thoughts on this.

While I'm a firm believer in the KISS principle, and in your specific case the 
step implementation strategy may be the simplest solution, I do think that 
there is a space for new features in the story/scenario specification area, 
notably to allow for their grouping (and hence also repetitions).

I've created a new issue to start gathering some focus:  
http://jira.codehaus.org/browse/JBEHAVE-873

Feel free to contribute thoughts and requirements.

Cheers

From: Iulian Greculescu [mailto:julian_grecule...@yahoo.com.au]
Sent: Tuesday, December 18, 2012 1:46 PM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Re: Repeating scenarios

At the point of writing this I am dealing with a similar problem. Stressing the 
system to its limits and see how it behaves under pressure by randomly running 
all the stories it supports millions of times during the night. At the end of 
the n hours run it triggers the execution of a final "step" that produces a 
detailed report about the load and the results, extracts error entries from the 
logs and calculates some statistics. This report is used next day by humans to 
assess the system health.

Just an idea about how we did it but of course there is always room for 
improvement.

Cheers,
Julian

--- On Wed, 19/12/12, Mary Walshe  wrote:

From: Mary Walshe 
Subject: Re: [jbehave-user] Re: Repeating scenarios
To: user@jbehave.codehaus.org
Received: Wednesday, 19 December, 2012, 12:41 AM
Thanks for you replies. I agree that it does not need to be something jbehave 
handles I was just wondering if it did.

It is a difficult case and it looks like we are going to get requirements in 
the future with the same criteria. Taking everything into account the test may 
end up taking a long time to run which wouldn't fit in with our CI and the idea 
of fast feedback.

We are going looking at taking the statistic out of the story and seeing if we 
can use our CI to handle such tests that allow a certain failure percentage. 
There just does not seem to be a silver bullet with this type of requirement.

Thank you for all your suggestions. I will pass them on to the developers. If 
we come to a nice solution for this case I'll follow up if you are interested.

On Tue, Dec 18, 2012 at 11:53 AM, Alexander Lehmann 
> wrote:
I think it would be possible to write a step similar to a composite step to run 
the necessary steps repeatedly and evaluate the result, however this has the 
disadvantage that the steps are hidden in the implementation of the step and 
not in the story file (and I think the steps are not reported individually), 
though maybe given stories may be a possibility.

When running individual steps with a statistical outcome, it would be necessary 
to keep the state somewhere to be able to evaluate the probability in the end, 
possibly in the page object, but this is difficult to do if there are different 
tests to be accounted when multi-threading.

One last thing I'd like to point out is that the evaluation of such a test is 
not deterministic unless you have a mockup service that actually returns a 
failure every n counts. When running the test 20 times, it would be valid to 
have 0 or 2+ failures sometimes, where it would be misleading to have the test 
fail. Maybe it would be feasible to run the 20 tests more than once in that 
case and calculate the average, but this is still a bit flaky to have a test 
failing when the expected value is not reached (either you need an estimator 
function and a confidence interval or you can just report the test result as 
warning with the calculated value)





-
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




On 18/12/2012 14:41, Mary Walshe wrote:
Thanks for you replies. I agree that it does not need to be something jbehave 
handles I was just wondering if it did.

It is a difficult case and it looks like we are going to get requirements in 
the future with the same criteria. Taking everything into account the test may 
end up taking a long time to run which wouldn't fit in with our CI and the idea 
of fas

RE: [jbehave-user] Bug in StoryManager regarding timeouts?

[Jorge Pombar]

We have also faced this issue before. I think is a bug on jbehave, can you 
please confirm?

To get around this we just set a super high timeout of 1 hour so the whole 
story file has time to run

Thanks,
Enrique

From: Andreas Ebbert-Karroum [mailto:andreas.ebbert-karr...@codecentric.de]
Sent: Monday, July 15, 2013 7:37 AM
To: user@jbehave.codehaus.org
Subject: [jbehave-user] Bug in StoryManager regarding timeouts?

Hi,

as I read the specification of a timeout, it is setting the controls to let a 
story time out, when a specified amount of time has passed. By the name this is 
a setting per story. So, when I have a timeout of 300s per story, I should be 
able to have 100 stories, which take 250 seconds each.

The way it is implemented is different, though. The StoryManager measures the 
start time right after it kicked off all stories, and is waiting for all of 
them to be completed.

https://github.com/jbehave/jbehave-core/blob/master/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java






public void waitUntilAllDoneOrFailed(BatchFailures failures) {




>>> long start = System.currentTimeMillis();




boolean allDone = false;




while (!allDone) {




allDone = true;
for (RunningStory runningStory : runningStories.values()) {




Future future = runningStory.getFuture();




if (!future.isDone()) {




allDone = false;
>>> long durationInSecs = storyDurationInSecs(start);




long timeoutInSecs = embedderControls.storyTimeoutInSecs();




>>> if (durationInSecs > timeoutInSecs) {




Story story = runningStory.getStory();




StoryDuration storyDuration = new 
StoryDuration(durationInSecs, timeoutInSecs);




embedderMonitor.storyTimeout(story, storyDuration);




storyRunner.cancelStory(story, storyDuration);




future.cancel(true);




}
break;

Is it just my thinking, or is that a bug in JBehave?




--
Mit freundlichen Grüßen / Best regards

Andreas Ebbert-Karroum | Agile Principal Consultant

codecentric AG | Merscheider Straße 1 | 42699 Solingen | Deutschland
tel: +49 (0) 212.23362825 | fax: +49 (0) 212.23362879 | mobil: +49 (0) 
175.2664109
www.codecentric.de | 
blog.codecentric.de | 
www.meettheexperts.de | 
www.more4fi.de

Sitz der Gesellschaft: Düsseldorf | HRB 63043
Vorstand: Klaus Jäger (Vorsitzender) . Michael Hochgürtel . Mirko Novakovic . 
Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Bernd Klinkmann . Jürgen Schütz

Diese E-Mail einschließlich evtl. beigefügter Dateien enthält vertrauliche 
und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige 
Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie 
bitte sofort den Absender und löschen Sie diese E-Mail und evtl. beigefügter 
Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder Öffnen evtl. beigefügter 
Dateien sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

RE: [jbehave-user] Execute all scenarios despite of failures

[Jorge Pombar]

Hi Bruno,
You can control this behavior via configuration. I'm assuming you are talking 
about scenarios on the same story file

The class that controls this on JBehave is 
"org.jbehave.core.embedder.StoryControls". I do find it weird that you see this 
behavior because I see that the default on this class is "private boolean 
skipScenariosAfterFailure = false;"

When you are configuring JBehave look for something like
configuration.useStoryControls

The other possibility is that your steps are actually PENDING and you don't an 
implementation of it with that annotation.

Thanks,
Enrique

From: Bruno Vercelino da Hora [mailto:brunodah...@gmail.com]
Sent: Thursday, September 12, 2013 8:24 AM
To: user@jbehave.codehaus.org
Subject: [jbehave-user] Execute all scenarios despite of failures

Hi, I'm using JBehave with JUnit.

I was able to configure and use it well.
But there is something that is bottering me.

When a scenario fails all the other scenarios aren't executed, they just show 
like PENDING.
Is there a way that despite a scenario fails the others will be executed?

Thanks for the help!

Bruno Vercelino da Hora
--
"Mas Deus prova o seu próprio amor para conosco pelo fato de ter Cristo morrido 
por nós, sendo nós ainda pecadores." - Romanos 5:8
"Mas em nada tenho a minha vida como preciosa para mim, contando que complete a 
minha carreira e o ministério que recebi do Senhor Jesus, para dar testemunho 
do evangelho da graça de Deus." - Atos 20:24

RE: [jbehave-user] Do I really need Page Objects?

[Jorge Pombar]

Hi Hans,
I have a different take. In my opinion PageObjects are a must if you are 
writing any test framework for any WebApp
The #1 reason is maintainability. WebApps by their nature change their GUI a 
lot. By calling a pageObject in your step and letting the pageObject take care 
of the browser interaction then you have a single point to maintain when 
something changes on that page.

This way your steps stay the same while you only change the pageObject when 
something changes on the page. Anyways, just my 2 cents. This is the way we 
have implemented it (and the recommended design pattern) and it works very well 
for us.

Thanks,
Enrique

From: Hans Schwäbli [mailto:bugs.need.love@gmail.com]
Sent: Monday, September 16, 2013 9:20 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Do I really need Page Objects?

Thank you for your answer.

By the way, I didn't want to compare JUnit and JBehave but intended to compare 
JUnit + Page Objects on one side with JBehave + Steps on the other side.

I think I won't use page objects since JBehave has steps. There is no need to 
write tests with JUnit side by side with JBehave. And I don't intend to be more 
independent of JBehave by having a page object layer.

Then I will see later if I really don't need page objects (but now I really 
think so).

2013/9/16 Mauro Talevi 
mailto:mauro.tal...@aquilonia.org>>
Hi Hans,

the short answer is no, you don't need to use page objects if you don't feel 
the need for them.

Page objects are a design paradigm that enable you to encapsulate the access to 
the business functionality exposed by the given web page and make it easier to 
maintain it, while possibly changing the underlying interaction, which can be 
at times rather complicated (web-speak and all).

The re-usability and readability criteria that you mention apply equally to 
JBehave and BDD as they do the JUnit and unit testing. Even more so, I would 
argue.   E.g. they can be re-used across multiple steps classes.

It is true though that page objects introduce another layer between steps and 
testing API, and it's up to you to decide if they are an advantage or a 
hindrance.You can also introduce them when they are needed and start off 
without them.

Cheers


On 16/09/2013 15:45, Hans Schwäbli wrote:
I started to write JBehave stories and steps and also page objects. Some 
examples of JBehave contain page objects, so I thought this is a good idea.
But now I ask myself what advantage there is if I write page objects? The steps 
which I write are re-usable and I can structure them in a similiar way like 
page objects (per page for instance).
Even today some people use JUnit for running GUI tests. I understand that you 
need page objects with JUnit, because of re-usability and readability.
But JBehave has its steps which are re-usable and readable, so why should I 
write page objects addionally? I see no advantage but more effort.
Did I overlook something? What would the disadvantage be of not using page 
objects with JBehave?

-
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

RE: [jbehave-user] Do I really need Page Objects?

[Jorge Pombar]

Hi Hans,
As you said "[Page Objects] is one way to achieve this, but not the only one". 
For us PageObjects have worked the best but that might not be the case for you. 
Let me leave you with some of the articles that I read when coming up with our 
design.

http://docs.seleniumhq.org/docs/06_test_design_considerations.jsp#page-object-design-pattern
http://code.google.com/p/selenium/wiki/PageObjects
http://code.google.com/p/selenium/wiki/PageFactory
http://code.google.com/p/selenium/wiki/LoadableComponent
http://assertselenium.com/automation-design-practices/page-object-pattern/

Happy JBehaving :)
Enrique

From: Hans Schwäbli [mailto:bugs.need.love@gmail.com]
Sent: Monday, September 16, 2013 11:20 PM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Do I really need Page Objects?


Hello Enrique,

doesn't JBehave steps provide already maintainability? I still don't see why I 
would need page objects when using JBehave.

If GUI changes, then the steps implementation can be changed. It is a single 
point to maintain if steps granularity is not too fine. The steps can take care 
of the browser interaction. The steps stay the same then, only their 
implementation changes if GUI changes.

Why should I use additional page objects for that? I don't see the advantage 
for maintainability. Page objects could make it easier to replace JBehave, but 
that is the only advantage I see.

Besides that, why should I re-model the GUI with page objects for the sake of 
maintainability? This is one way to achieve this, but not the only one. Any 
modularization will achieve this. And one way of modularization are step 
methods, provided they have not a too fine granularity.

I feel that using steps I am not so dependent on GUI changes compared to using 
page objects. For instance, if the login stretches across two pages and they 
change that to a single login page, I would have to re-model and refactor the 
page objects. But if I use a step method like "login(user, password, 
extraInfo)", the only thing I would need to update is the method implementation 
of the step.

JBehave is already a test framework to me. I may write a little framework 
around it in order to customize it, but no more.

These are my thoughts to your objection.

2013/9/16 Jorge Pombar 
mailto:jorge_pom...@symantec.com>>
Hi Hans,
I have a different take. In my opinion PageObjects are a must if you are 
writing any test framework for any WebApp
The #1 reason is maintainability. WebApps by their nature change their GUI a 
lot. By calling a pageObject in your step and letting the pageObject take care 
of the browser interaction then you have a single point to maintain when 
something changes on that page.

This way your steps stay the same while you only change the pageObject when 
something changes on the page. Anyways, just my 2 cents. This is the way we 
have implemented it (and the recommended design pattern) and it works very well 
for us.

Thanks,
Enrique

From: Hans Schwäbli 
[mailto:bugs.need.love@gmail.com<mailto:bugs.need.love@gmail.com>]
Sent: Monday, September 16, 2013 9:20 AM
To: user@jbehave.codehaus.org<mailto:user@jbehave.codehaus.org>
Subject: Re: [jbehave-user] Do I really need Page Objects?

Thank you for your answer.

By the way, I didn't want to compare JUnit and JBehave but intended to compare 
JUnit + Page Objects on one side with JBehave + Steps on the other side.

I think I won't use page objects since JBehave has steps. There is no need to 
write tests with JUnit side by side with JBehave. And I don't intend to be more 
independent of JBehave by having a page object layer.

Then I will see later if I really don't need page objects (but now I really 
think so).

2013/9/16 Mauro Talevi 
mailto:mauro.tal...@aquilonia.org>>
Hi Hans,

the short answer is no, you don't need to use page objects if you don't feel 
the need for them.

Page objects are a design paradigm that enable you to encapsulate the access to 
the business functionality exposed by the given web page and make it easier to 
maintain it, while possibly changing the underlying interaction, which can be 
at times rather complicated (web-speak and all).

The re-usability and readability criteria that you mention apply equally to 
JBehave and BDD as they do the JUnit and unit testing. Even more so, I would 
argue.   E.g. they can be re-used across multiple steps classes.

It is true though that page objects introduce another layer between steps and 
testing API, and it's up to you to decide if they are an advantage or a 
hindrance.You can also introduce them when they are needed and start off 
without them.

Cheers


On 16/09/2013 15:45, Hans Schwäbli wrote:
I started to write JBehave stories and steps and also page objects. Some 
examples of JBehave contain page objects, so I thought this is a good idea.
But now I ask myself what advantage there is if I write p

RE: [jbehave-user] Do I really need Page Objects?

[Jorge Pombar]

Hi Hans,
I believe I provided links to articles that explained the reasons why we like 
PageObjects. I would be repeating the same arguments (probably in worst 
English) that they did. Once again is design is very subjective and as you 
pointed out there is more than 1 right answer.

Thanks,
Enrique

From: Hans Schwäbli [mailto:bugs.need.love@gmail.com]
Sent: Thursday, September 19, 2013 5:02 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Do I really need Page Objects?

Hi Enrique,

I wrote concrete arguments against using page objects together with JBehave 
since I think they are redundant when using the steps of JBehave. I wished you 
would explain why you think that my arguments are not valid in your case.

It does not help me if you say "PageObjects have worked the best". This 
statement is very general and explains not why my objections don't apply in 
your case.

The only advantage I see in using Page Objects with JBehave is to be more 
independant of JBehave. But the price is redundancy and an additional (not 
required) layer to maintain and higher code complexity.

In ealier times (and often today) GUI tests with Selenium were written with 
JUnit. Page Objects or something like it was required then. But with JBehave 
you already have to write steps (which is "something like it"). So why do you 
think page objects are not redundant then? Where do you see the benefit of 
writing Page Objects for JBehave tests if you already have JBehave steps which 
contain the logic to do business logic on the screen?

Please explain it to me, I am very curious.



2013/9/18 Jorge Pombar 
mailto:jorge_pom...@symantec.com>>
Hi Hans,
As you said "[Page Objects] is one way to achieve this, but not the only one". 
For us PageObjects have worked the best but that might not be the case for you. 
Let me leave you with some of the articles that I read when coming up with our 
design.

http://docs.seleniumhq.org/docs/06_test_design_considerations.jsp#page-object-design-pattern
http://code.google.com/p/selenium/wiki/PageObjects
http://code.google.com/p/selenium/wiki/PageFactory
http://code.google.com/p/selenium/wiki/LoadableComponent
http://assertselenium.com/automation-design-practices/page-object-pattern/

Happy JBehaving :)
Enrique

From: Hans Schwäbli 
[mailto:bugs.need.love@gmail.com<mailto:bugs.need.love@gmail.com>]
Sent: Monday, September 16, 2013 11:20 PM

To: user@jbehave.codehaus.org<mailto:user@jbehave.codehaus.org>
Subject: Re: [jbehave-user] Do I really need Page Objects?


Hello Enrique,

doesn't JBehave steps provide already maintainability? I still don't see why I 
would need page objects when using JBehave.

If GUI changes, then the steps implementation can be changed. It is a single 
point to maintain if steps granularity is not too fine. The steps can take care 
of the browser interaction. The steps stay the same then, only their 
implementation changes if GUI changes.

Why should I use additional page objects for that? I don't see the advantage 
for maintainability. Page objects could make it easier to replace JBehave, but 
that is the only advantage I see.

Besides that, why should I re-model the GUI with page objects for the sake of 
maintainability? This is one way to achieve this, but not the only one. Any 
modularization will achieve this. And one way of modularization are step 
methods, provided they have not a too fine granularity.

I feel that using steps I am not so dependent on GUI changes compared to using 
page objects. For instance, if the login stretches across two pages and they 
change that to a single login page, I would have to re-model and refactor the 
page objects. But if I use a step method like "login(user, password, 
extraInfo)", the only thing I would need to update is the method implementation 
of the step.

JBehave is already a test framework to me. I may write a little framework 
around it in order to customize it, but no more.

These are my thoughts to your objection.

2013/9/16 Jorge Pombar 
mailto:jorge_pom...@symantec.com>>
Hi Hans,
I have a different take. In my opinion PageObjects are a must if you are 
writing any test framework for any WebApp
The #1 reason is maintainability. WebApps by their nature change their GUI a 
lot. By calling a pageObject in your step and letting the pageObject take care 
of the browser interaction then you have a single point to maintain when 
something changes on that page.

This way your steps stay the same while you only change the pageObject when 
something changes on the page. Anyways, just my 2 cents. This is the way we 
have implemented it (and the recommended design pattern) and it works very well 
for us.

Thanks,
Enrique

From: Hans Schwäbli 
[mailto:bugs.need.love@gmail.com<mailto:bugs.need.love@gmail.com>]
Sent: Monday, September 16, 2013 9:20 AM
To: user@jbehave.codehaus.org<mailto:user@jbehave.codehaus.or

RE: [jbehave-user] JBehave and Selenium

[Jorge Pombar]

It's true that the current version of Jbehave Web (3.5.5) doesn't work w 
Seleniun-java v2.34.0 or above
I reported this bug (https://jira.codehaus.org/browse/JBEHAVE-941) and it has 
already been fixed for the JBehave Web 3.6 release
I don't know when this version would be released but I hope is soon

Thanks,
Enrique

From: Hans Schwäbli [mailto:bugs.need.love@gmail.com]
Sent: Thursday, September 19, 2013 7:50 AM
To: user@jbehave.codehaus.org
Subject: [jbehave-user] JBehave and Selenium

I think there is a version of JBehave with integrated Selenium support (I think 
it was "jbehave-web").

But I discovered that it uses an old version of Selenium.

So I thought not to use JBehave with integrated Selenium support but to use 
JBehave Core and to use the latest Selenium version or any version I want.

I might lose some integration benefits, but then I am free to use the Selenium 
version I need or want and not the one, which is currently supported by JBehave.

Do you think this is a good idea?

RE: [jbehave-user] JBehave and Selenium

[Jorge Pombar]

Hi Mauro,
I have verified the latest 3.6.SNAPSHOT with selenium-java v2.35.0 and 
IEDriverServer_Win32_2.25.3
Everything builds and runs perfectly. Thanks again for the quick fix!

I have updated the artf with the same info. Once you push the release to Maven 
Central, I’ll pick it up from there.

Thanks,
Enrique

From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
Sent: Thursday, September 19, 2013 10:11 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] JBehave and Selenium

Hi Jorge,

if you've tested and validated the latest snapshot we can release 3.6
Cheers

On 19 Sep 2013, at 17:51, Jorge Pombar 
mailto:jorge_pom...@symantec.com>> wrote:
It’s true that the current version of Jbehave Web (3.5.5) doesn’t work w 
Seleniun-java v2.34.0 or above
I reported this bug (https://jira.codehaus.org/browse/JBEHAVE-941) and it has 
already been fixed for the JBehave Web 3.6 release
I don’t know when this version would be released but I hope is soon

Thanks,
Enrique

From: Hans Schwäbli [mailto:bugs.need.love@gmail.com]
Sent: Thursday, September 19, 2013 7:50 AM
To: user@jbehave.codehaus.org<mailto:user@jbehave.codehaus.org>
Subject: [jbehave-user] JBehave and Selenium

I think there is a version of JBehave with integrated Selenium support (I think 
it was "jbehave-web").

But I discovered that it uses an old version of Selenium.

So I thought not to use JBehave with integrated Selenium support but to use 
JBehave Core and to use the latest Selenium version or any version I want.

I might lose some integration benefits, but then I am free to use the Selenium 
version I need or want and not the one, which is currently supported by JBehave.

Do you think this is a good idea?

RE: [jbehave-user] Do I really need Page Objects?

[Jorge Pombar]

Hello Hans,
"I bet you will now point me to read some books instead of arguing against my 
arguments"
That's the key point to me. You are looking for an argument and I'm not. My 
purpose was just to offer my 2 cent in case it helped you or someone else. It 
looks like my 2 cents won't help you and that's ok.

I won't reply to this thread anymore as I don't have anything else to add. I 
wish you all the best in your project and design. And I hope you have as much 
fun working with this great framework, that Mauro and others have generously 
build and do a great job at maintaining, as we do.

Happy JBehaving!
Enrique

From: Hans Schwäbli [mailto:bugs.need.love@gmail.com]
Sent: Monday, September 23, 2013 6:04 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Do I really need Page Objects?

Hello Enrique,

it is a bit disappointing to me if you point me to a lot of articles which are 
not suitable for my arguments.

You mention Selenium articles. They assume that tests are written as JUnit 
tests. They do not assume that JBehave or BDD is used instead. The arguments in 
the Selenium articles apply if you use something like JUnit to write tests. But 
they don't apply for JBehave in my eyes.

These articles mention these reasons for having page objects:

* Reduces the duplication of code
* Makes tests more readable and robust
* Improves the maintainability of tests, particularly when there is frequent 
change in the AUT. (Useful in Agile methodology based projects)
* There is no separation between the test method and the AUTs locators
* The id-locators would be spread in multiple tests

All this can be achieved by using JBehave steps, provided they are abstract 
enough (not a too fine granularity of steps).

I bet you will now point me to read some books instead of arguing against my 
arguments ...

2013/9/19 Jorge Pombar 
mailto:jorge_pom...@symantec.com>>
Hi Hans,
I believe I provided links to articles that explained the reasons why we like 
PageObjects. I would be repeating the same arguments (probably in worst 
English) that they did. Once again is design is very subjective and as you 
pointed out there is more than 1 right answer.

Thanks,
Enrique

From: Hans Schwäbli 
[mailto:bugs.need.love@gmail.com<mailto:bugs.need.love@gmail.com>]
Sent: Thursday, September 19, 2013 5:02 AM

To: user@jbehave.codehaus.org<mailto:user@jbehave.codehaus.org>
Subject: Re: [jbehave-user] Do I really need Page Objects?

Hi Enrique,

I wrote concrete arguments against using page objects together with JBehave 
since I think they are redundant when using the steps of JBehave. I wished you 
would explain why you think that my arguments are not valid in your case.

It does not help me if you say "PageObjects have worked the best". This 
statement is very general and explains not why my objections don't apply in 
your case.

The only advantage I see in using Page Objects with JBehave is to be more 
independant of JBehave. But the price is redundancy and an additional (not 
required) layer to maintain and higher code complexity.

In ealier times (and often today) GUI tests with Selenium were written with 
JUnit. Page Objects or something like it was required then. But with JBehave 
you already have to write steps (which is "something like it"). So why do you 
think page objects are not redundant then? Where do you see the benefit of 
writing Page Objects for JBehave tests if you already have JBehave steps which 
contain the logic to do business logic on the screen?

Please explain it to me, I am very curious.



2013/9/18 Jorge Pombar 
mailto:jorge_pom...@symantec.com>>
Hi Hans,
As you said "[Page Objects] is one way to achieve this, but not the only one". 
For us PageObjects have worked the best but that might not be the case for you. 
Let me leave you with some of the articles that I read when coming up with our 
design.

http://docs.seleniumhq.org/docs/06_test_design_considerations.jsp#page-object-design-pattern
http://code.google.com/p/selenium/wiki/PageObjects
http://code.google.com/p/selenium/wiki/PageFactory
http://code.google.com/p/selenium/wiki/LoadableComponent
http://assertselenium.com/automation-design-practices/page-object-pattern/

Happy JBehaving :)
Enrique

From: Hans Schwäbli 
[mailto:bugs.need.love@gmail.com<mailto:bugs.need.love@gmail.com>]
Sent: Monday, September 16, 2013 11:20 PM

To: user@jbehave.codehaus.org<mailto:user@jbehave.codehaus.org>
Subject: Re: [jbehave-user] Do I really need Page Objects?


Hello Enrique,

doesn't JBehave steps provide already maintainability? I still don't see why I 
would need page objects when using JBehave.

If GUI changes, then the steps implementation can be changed. It is a single 
point to maintain if steps granularity is not too fine. The steps can take care 
of the browser interaction. The steps stay the same then, on

RE: [jbehave-user] Support for dynamic variables?

[Jorge Pombar]

We also have several scenarios where the input for the scenarios are determined 
at runtime.

I think Paul offered a good solution, create a variable in the pageObject and 
set it (by the When step) then you can get it (on the Then step) for 
verification (I think we'll give this approach a chance)

Another solution is to have a static map where you set it and then retrieve it 
when needed. This is what we have implemented and it works for us.

Thanks,
Enrique

From: Hans Schwäbli [mailto:bugs.need.love@gmail.com]
Sent: Thursday, October 31, 2013 8:24 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Support for dynamic variables?

I see. So there is no use looking for a existing JBehave feature for this.

I meant dynamic variables which are set and used at runtime. There are cases 
where one has to automate tests on non-deterministic test data (I mean the data 
of the application under test).

A "life cycle" of these variables might be an issue in future. Currently I 
cannot tell you a real world use case for it. But I think there might be the 
need to configure the scope of such dynamic variables to be existing per 
stories, per story or per scenario. This would require a close integration into 
JBehave execution procedure.

The easiest could be to store the variables for the whole execution and to 
clear them if needed in steps annotated with @BeforeStory for instance.

I have to think a bit on how I could solve this in a suitable and good way.

2013/10/31 Mauro Talevi 
mailto:mauro.tal...@aquilonia.org>>
Typically you would define an API to access these variables.   This is 
something that you cannot really generalise.

If on the other hand you know these variable at execution time, you could pass 
them as system properties in the jbehave maven goal or ant task.


On 31 Oct 2013, at 11:12, Hans Schwäbli 
mailto:bugs.need.love@gmail.com>> wrote:

> For some stories and scenarios I need dynamic variables which are determined 
> at runtime.
>
> Example: I want to store the balance of an account, do some transactions and 
> then expect that the balance is increased by 1000 for instance. If your test 
> data are not deterministic you need such approaches.
>
> Is there a JBehave feature for this, storing such dynamic variables at 
> runtime and accessing them at runtime across scenarios and stories?
>
> Or do I have to implement that myself in my steps?
-
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

RE: [jbehave-user] Support for dynamic variables?

[Jorge Pombar]

Hi Hans,
As I mentioned we had the same problem (generating some data dynamically that 
Step1 uses and then Step2 needs for verification) and I was simply sharing how 
we solved it in case you find it useful

Again we have a static map inside a static class. We call it ThreadLocalUtils 
the map is ThreadSafe and it lives for the duration of the execution of all 
stories. Here we store the value w a predefined key (scenarioID + "someString") 
on Step1. We later retrieve the value when we need it in Step2

Here is the declaration of the collection
private static final ThreadLocal> threadLocal = new 
ThreadLocal>() {
@Override
protected java.util.Map 
initialValue() {
logger.info("[ThreadLocalUtil] 
Creating the thread local map for the first time for thread [{}].", 
Thread.currentThread().getName());
return new HashMap();
};
};

I also said that I liked the idea of adding a variable in the pageObject that 
stores it (we have implemented it and it also works). For instance on the 
CheckingAccount pageObject you can have a variable "latestDeposit". Here we 
would save the deposit amount generated on Step1 and then simple retrieve it on 
Step2 when we need it. Hope this helps.

Thanks,
Enrique

From: Hans Schwäbli [mailto:bugs.need.love@gmail.com]
Sent: Tuesday, November 05, 2013 7:15 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Support for dynamic variables?

Enrique, I was asking for information not demanding a feature.

Can you guarantee that that page object implementation works for everyone or 
works at all?

What if JBehave instantiates new Steps from time to time? The dynamic variables 
would be gone. When implementing dynamic variables JBehave framework has to be 
considered since it runs the steps in its own way and you have not much control 
over it, whether it instantiates new Steps or uses the same. Is there a 
contract for this? If not, what if JBehave implementation is changed and this 
solution does not work anymore? I think it is worth thinking a bit about the 
consequences.

And what if you run parallel stories. Is it guaranteed that each run will have 
its own step objects or will they be shared?

What about life cycle issues? What if you want to clean all dynamic variables 
after each story has run for instance? That would require some design and being 
embedded in the story run machine.

And is it such a far fetched thing to suppose that JBehave might support 
dynamic variables for the runtime if it already supports variables which are 
set at "compile" time?

As I said, I am not demanding anything, but I think a few thoughts about this 
(or questions how others have done it) are no bad idea before implementing 
dynamic variables.

2013/10/31 Jorge Pombar 
mailto:jorge_pom...@symantec.com>>
We also have several scenarios where the input for the scenarios are determined 
at runtime.

I think Paul offered a good solution, create a variable in the pageObject and 
set it (by the When step) then you can get it (on the Then step) for 
verification (I think we'll give this approach a chance)

Another solution is to have a static map where you set it and then retrieve it 
when needed. This is what we have implemented and it works for us.

Thanks,
Enrique

From: Hans Schwäbli 
[mailto:bugs.need.love@gmail.com<mailto:bugs.need.love@gmail.com>]
Sent: Thursday, October 31, 2013 8:24 AM
To: user@jbehave.codehaus.org<mailto:user@jbehave.codehaus.org>
Subject: Re: [jbehave-user] Support for dynamic variables?

I see. So there is no use looking for a existing JBehave feature for this.

I meant dynamic variables which are set and used at runtime. There are cases 
where one has to automate tests on non-deterministic test data (I mean the data 
of the application under test).

A "life cycle" of these variables might be an issue in future. Currently I 
cannot tell you a real world use case for it. But I think there might be the 
need to configure the scope of such dynamic variables to be existing per 
stories, per story or per scenario. This would require a close integration into 
JBehave execution procedure.

The easiest could be to store the variables for the whole execution and to 
clear them if needed in steps annotated with @BeforeStory for instance.

I have to think a bit on how I could solve this in a suitable and good way.

2013/10/31 Mauro Talevi 
mailto:mauro.tal...@aquilonia.org>>
Typically you would define an API to access these variables.   This is 
something that you cannot really generalise.

If on the other hand you know these variable at execution time, you could pass 
them as system properties in the jbehave maven goal or ant task.


On 31 Oct 2013, at 11:12, Hans Schwäbli 

RE: [jbehave-user] How to run specific .story file from IDE

[Jorge Pombar]

Hi Marius,
Full disclosure I don't use Intellij, we use Eclipse instead. Let me share what 
I know
JBehave will run all the stories that this method returns
[cid:image001.png@01CEF721.23A3EC90]List>
 storyPaths()

I think that the default implementation is that it finds all the ".story" files 
found in the target dir.
We overwrote the method in order to be able to choose which story to run

Our implementation has 2 flows:

* If a System prop we call storyFilter is defined then we only run the 
stories that match it (we use this when running from cmd line)
if(storyFilter != null) {
  //if this param is set then only run the those stories
  return new 
StoryFinder().findPaths(codeLocationFromClass(this.getClass()).getFile(), 
asList("**/" +
  storyFilter + ".story"), null);
}

* Otherwise, we have a separate "allStories.seq" file that lists all of 
our stories. This flow reads this file and returns all the stories that are not 
commented out as a list.

This is how we control what stories we want to run on each execution.

Thanks,
Enrique

From: Marius Bob [mailto:znu...@gmail.com]
Sent: Thursday, December 12, 2013 8:29 AM
To: user@jbehave.codehaus.org
Subject: [jbehave-user] How to run specific .story file from IDE


How to tell jBehave to run specific .story files? I'm using Intellij IDEA

Let's say I have 3 .story files which include different scenarios and, at some 
point, I want to run only a .story file.



I don't figure out from the documentation. Maybe I'm missing something again



Thanks



<>

RE: [jbehave-user] Differentiating between test failures and test errors

[Jorge Pombar]

Mauro,
I've been hearing of really great improvement for 4.0 for a while. Do you have 
a feature list for 4.0? Also do you have an ETA of a non Beta release?

Thanks,
Enrique


-Original Message-
From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org] 
Sent: Sunday, January 19, 2014 8:42 AM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Differentiating between test failures and test 
errors

I would not really go down that route.

In 4.x StoryRunner will be completely replaced by a different tree-based 
execution engine called PerformableTree.The idea is to create a tree 
of performable objects that can contain runtime results which can then be 
rendered in a template, thereby rendering the story reporter obsolete.

I'd prefer you gave the latest 4.0-beta-4 a whirl (I've released it today and 
it should be synched soon to Maven Central).

You could start by creating a new JIRA issue outlining your use case and we 
take it from there.

On 19/01/2014 12:05, Stephen de Vries wrote:
> Thank Mauro,
>
> Ideally, I'd like to see the error in the xml and html files, e.g.   outcome="error"> , so it sounds like I'd have to re-implement StoryRunner and 
> create a custom StoryReporter to achieve this?  Is there an easier way?
>
>
>
>
> On 19 Jan 2014, at 11:21, Mauro Talevi  wrote:
>
>> JBehave supports the definition of a custom and configurable 
>> FailureStrategy, which defaults to RethrowingFailure.
>>
>> You can provide your own implementation which can check if the Throwable is 
>> an UnexpectedContentException or not and decide how to handle it, e.g. log a 
>> message and swallow the exception.
>>
>> Be aware though that if you do rethrow the exception, it'll be treated by 
>> the JBehave story execution as a failure.   So there is no specific 
>> mechanism to distinguish the failures thereafter.
>>
>> On 19/01/2014 09:54, Stephen de Vries wrote:
>>> Hi,
>>>
>>> Is there a mechanism in JBehave to differentiate between a scenario failure 
>>> and a scenario error?  Basically, when a scenario fails I'd like to know 
>>> whether it's a problem with my test, or a problem with the application 
>>> under test.
>>>
>>> I'm using JBehave for security tests, so a scenario failure indicates a 
>>> security vulnerability; but I have error checking logic in the test itself 
>>> which just ensures that the test is behaving properly, so if there's an 
>>> error in the test then I don't want the test to "fail" but rather to throw 
>>> some kind of distinguishable error condition, like in the following 
>>> contrived example:
>>>
>>> @Then("bob must not see alice's private data") public void 
>>> checkAccessControl() {
>>> loginAsBob();
>>> driver.get(bobsPage);
>>>  if (notOnBobsPage()) throw UnexpectedContentException("Can't 
>>> access bob's page even though bob is logged in"); //Test error
>>>   driver.get(alicesPage);
>>>  assertThat("bob can see alices data", canViewAlicesData(), 
>>> is(true));  //Application error and security vulnerability }
>>>  In the case above, I'd like the scenario outcome to be different 
>>> if assertion fails vs if the UnexpectedContentException is thrown.   If 
>>> there's no native way to do this in JBehave, do you have any ideas on the 
>>> easiest way to achieve this?
>>>
>>> regards,
>>> Stephen
>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>> - To unsubscribe from this list, please visit:
>>>
>>>  http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>> -
>> To unsubscribe from this list, please visit:
>>
>>http://xircles.codehaus.org/manage_email
>>
>>
>
> -
> To unsubscribe from this list, please visit:
>
>  http://xircles.codehaus.org/manage_email
>
>


-
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email



-
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

RE: [jbehave-user] Reset State in Parameterized Scenario

[Jorge Pombar]

I had a similar use case and we did the following:

* Defined all the @Before/After annotations in a LifecycleSteps class 
that extends org.jbehave.web.selenium.PerStoryWebDriverSteps

* These steps can take the Meta tags as input. Hence we define a meta 
that looks like "@resetAcctPolsToDefaulsOnFailure true" for the scenarios in 
which we wanted to reset

* Inside the method we check if this is defined and true and then do 
the resetting

Our code looks something like this
@AfterScenario(uponOutcome=Outcome.FAILURE)
public void 
resetAcctPolsToDefaulsOnFailure(@Named("resetAcctPolsToDefaulsOnFailure")String 
resetAcctPolsToDefaulsOnFailure) {
 logger.debug("[resetAcctPolsToDefaulsOnFailure] Scenario failed inside");
 if(new Boolean(resetVipAcctPolsToDefaulsOnFailure)) {
   logger.info("[resetVipAcctPolsToDefaulsOnFailure] Reseting VIP 
Account tab policies back to default");
//resetting code here
 }
 else
   logger.debug("[resetAcctPolsToDefaulsOnFailure] MetaTag 
resetVipAcctPolsToDefaulsOnFailure [{}] NOT RESETING VIP Account tab policies 
back to default", resetVipAcctPolsToDefaulsOnFailure);
}


Thanks,
Enrique

From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
Sent: Monday, January 27, 2014 12:35 PM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] Reset State in Parameterized Scenario

Hi,

the @Before/After annotations are not able to take any runtime parameters.

If you want to reset after a single parametrised scenario then you can simply 
define a reset step and make it part of the scenario.

Cheers

On 27/01/2014 15:26, Corbin, J.D. wrote:
Hi Mauro,

Thanks for that suggestion.  It happens to work in my case since I only have 
one parameterized scenario, but what if I had two and only wanted the reset 
behavior for a single parameterized scenario.  Is that possible?  I would think 
the scenario would have to be named in some way.

J.D.

On Sat, Jan 25, 2014 at 2:21 AM, Mauro Talevi 
mailto:mauro.tal...@aquilonia.org>> wrote:
Use annotation specifying the scenario type

@BeforeScenario(uponType=ScenarioType.EXAMPLE)

Cheers


On 24/01/2014 23:14, Corbin, J.D. wrote:
We are using the tabular scenario format to run multiple sets of data through a 
single jbehave scenario using the Examples: tabular format.

We are using a custom scenario scope that has our global scenario state.  Using 
this approach, we get a new instance of our global state object at the 
beginning of each scenario which is what we want.

The problem is that there is some state we'd like to reset in between the 
tabular runs for the scenario but I don't see where to inject some behavior 
into JBehave.  JBehave doesn't treat each run as a new scenario, just runs the 
new set of parameterized data through the same scenario instance, so we cannot 
figure out where to reset the state in between the runs.  We have gotten around 
this by resetting the state in one of the steps of the scenario but this is not 
ideal because its possible that this step is used in other scenarios and we 
don't necessary want this state reset in those cases.

Is there such a thing as tabular scope or some place we can introduce some 
behavior in between parameterized runs of a single scenario?

J.D.


-
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email