[jbehave-user] CTRL+F does not work in JBehave editor
As it seems CTRL+F for searching text does not work inside the JBehave editor. What do you think, would that be a good idea to add that feature to the JBehave editor?
Re: [jbehave-user] Question regarding WebDriverScreenshotOnFailure
Ah, okay. They will have a good reason for that I guess. On Mon, Jun 30, 2014 at 4:34 PM, Mauro Talevi wrote: > At class level, not method level. > > On 30 Jun 2014, at 15:33, Hans Schwäbli > wrote: > > I thought there is a way to make annotations to be inherited by subclasses. > > But I don't know and thats a bit off-topic currently. Maybe I dig later > deepter in that issue. > > > On Mon, Jun 30, 2014 at 1:23 PM, Mauro Talevi > wrote: > >> Not sure I understand. That's the nature of Java annotations. >> >> > On 30 Jun 2014, at 09:52, Hans Schwäbli >> wrote: >> > >> > I have subclassed WebDriverScreenshotOnFailure and overridden >> afterScenarioFailure(UUIDExceptionWrapper). >> > >> > I wondered why my class never was used. Then I discovered that I have >> to add the same annotation in the overriden method like it is in the >> superclass: >> > >> > @AfterScenario(uponOutcome = Outcome.FAILURE) >> > >> > Do you intend not to "inherit" this annotation to sub classes when >> afterScenarioFailure(UUIDExceptionWrapper) is overridden? >> >> - >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >
Re: [jbehave-user] Re: ContextView still works in 4.0-beta-7?
What do you mean with "it seems the problem is with web only"? There is only one Context class: org.jbehave.core.context.Context Do you mean that jbehave-web somehow causes this issue in the 4.x branch because of WIP? By the way, when do you expect that the 4.x branch will become non-beta? On Mon, Jun 30, 2014 at 1:21 PM, Mauro Talevi wrote: > Thanks, started looking at it and it seems the problem is with web only, > core context view works fine. > > Because web has its own context which will be removed to use the core one > in 4.x. > > WIP ... > > On 27 Jun 2014, at 11:28, Hans Schwäbli > wrote: > > I created it: https://jira.codehaus.org/browse/JBEHAVE-1030 > > In the second part of the article I wrote that in 4.x the context view can > be still used like in JBehave 3.9.2. I hope that will be okay. > > > On Tue, Jun 24, 2014 at 11:33 AM, Mauro Talevi > wrote: > >> Can you please raise a JIRA issue for this so it doesn't get lost in >> translation? :-) >> >> On 24 Jun 2014, at 08:40, Hans Schwäbli >> wrote: >> >> It also occurs with 4.0-beta-8. >> >> Did you have a chance to reproduce this issue with the information I >> posted before? >> >> >> On Mon, Jun 16, 2014 at 11:53 AM, Hans Schwäbli < >> bugs.need.love@gmail.com> wrote: >> >>> >>> By the way: You can reproduce it with the same example which I mentioned >>> in another issue: https://github.com/OttoDiesel/ >>> jbehave-selenium-example.git >>> >>> >>> -- Forwarded message -- >>> From: Hans Schwäbli >>> Date: Mon, Jun 16, 2014 at 8:56 AM >>> Subject: ContextView still works in 4.0-beta-7? >>> To: user@jbehave.codehaus.org >>> >>> >>> I changed a project from JBehave 3.9.2 to 4.0-beta-7. >>> >>> This made the context view disappear. I use the same code for applying >>> the context view like I see in the JBehave examples today >>> (org.jbehave.examples.core.CoreStories). >>> >>> Does the ContextView still work in JBehave 4.0-beta-7? >>> >>> >> >
Re: [jbehave-user] Question regarding WebDriverScreenshotOnFailure
I thought there is a way to make annotations to be inherited by subclasses. But I don't know and thats a bit off-topic currently. Maybe I dig later deepter in that issue. On Mon, Jun 30, 2014 at 1:23 PM, Mauro Talevi wrote: > Not sure I understand. That's the nature of Java annotations. > > > On 30 Jun 2014, at 09:52, Hans Schwäbli > wrote: > > > > I have subclassed WebDriverScreenshotOnFailure and overridden > afterScenarioFailure(UUIDExceptionWrapper). > > > > I wondered why my class never was used. Then I discovered that I have to > add the same annotation in the overriden method like it is in the > superclass: > > > > @AfterScenario(uponOutcome = Outcome.FAILURE) > > > > Do you intend not to "inherit" this annotation to sub classes when > afterScenarioFailure(UUIDExceptionWrapper) is overridden? > > - > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
[jbehave-user] Question regarding WebDriverScreenshotOnFailure
I have subclassed WebDriverScreenshotOnFailure and overridden afterScenarioFailure(UUIDExceptionWrapper). I wondered why my class never was used. Then I discovered that I have to add the same annotation in the overriden method like it is in the superclass: @AfterScenario(uponOutcome = Outcome.FAILURE) Do you intend not to "inherit" this annotation to sub classes when afterScenarioFailure(UUIDExceptionWrapper) is overridden?
Re: [jbehave-user] Re: ContextView still works in 4.0-beta-7?
I created it: https://jira.codehaus.org/browse/JBEHAVE-1030 In the second part of the article I wrote that in 4.x the context view can be still used like in JBehave 3.9.2. I hope that will be okay. On Tue, Jun 24, 2014 at 11:33 AM, Mauro Talevi wrote: > Can you please raise a JIRA issue for this so it doesn't get lost in > translation? :-) > > On 24 Jun 2014, at 08:40, Hans Schwäbli > wrote: > > It also occurs with 4.0-beta-8. > > Did you have a chance to reproduce this issue with the information I > posted before? > > > On Mon, Jun 16, 2014 at 11:53 AM, Hans Schwäbli < > bugs.need.love@gmail.com> wrote: > >> >> By the way: You can reproduce it with the same example which I mentioned >> in another issue: https://github.com/OttoDiesel/ >> jbehave-selenium-example.git >> >> >> -- Forwarded message -- >> From: Hans Schwäbli >> Date: Mon, Jun 16, 2014 at 8:56 AM >> Subject: ContextView still works in 4.0-beta-7? >> To: user@jbehave.codehaus.org >> >> >> I changed a project from JBehave 3.9.2 to 4.0-beta-7. >> >> This made the context view disappear. I use the same code for applying >> the context view like I see in the JBehave examples today >> (org.jbehave.examples.core.CoreStories). >> >> Does the ContextView still work in JBehave 4.0-beta-7? >> >> >
[jbehave-user] Re: ContextView still works in 4.0-beta-7?
It also occurs with 4.0-beta-8. Did you have a chance to reproduce this issue with the information I posted before? On Mon, Jun 16, 2014 at 11:53 AM, Hans Schwäbli < bugs.need.love@gmail.com> wrote: > > By the way: You can reproduce it with the same example which I mentioned > in another issue: https://github.com/OttoDiesel/ > jbehave-selenium-example.git > > > -- Forwarded message -- > From: Hans Schwäbli > Date: Mon, Jun 16, 2014 at 8:56 AM > Subject: ContextView still works in 4.0-beta-7? > To: user@jbehave.codehaus.org > > > I changed a project from JBehave 3.9.2 to 4.0-beta-7. > > This made the context view disappear. I use the same code for applying the > context view like I see in the JBehave examples today > (org.jbehave.examples.core.CoreStories). > > Does the ContextView still work in JBehave 4.0-beta-7? > >
Re: [jbehave-user] Filtering works not as expected with a scenario containing an examples table
Thank you very much. It works now with my example. On Wed, Jun 18, 2014 at 6:39 PM, Mauro Talevi wrote: > 4.0-beta-8 has just been released, with the agreed keywords. > > On 18/06/2014 08:55, Hans Schwäbli wrote: > > When will there be a beta-8 version of the 4.x branch containing this > fix? > > I am asking because the examples for the JBehave article will need that, > and the magazine is published on 2nd of July. > > > On Wed, May 21, 2014 at 8:50 AM, Mauro Talevi > wrote: > >> Sold! To the German-speaking gentleman at the back of the room :-) >> >> >> On 20/05/2014 21:00, Mirko Friedenhagen wrote: >> >>> Hans, >>> >>> I stand corrected, in this case JEDES is a better translation for ANY. >>> And make FAILURE FEHLER. >>> Regards Mirko >>> -- >>> http://illegalstateexception.blogspot.com/ >>> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) >>> https://bitbucket.org/mfriedenhagen/ >>> >>> >>> On Tue, May 20, 2014 at 10:14 AM, Hans Schwäbli >>> wrote: >>> >>>> Mirko, I suppose you are a native German speaker like me, right? >>>> >>>> What is your message? That the current German translations for ANY and >>>> FAILURE are the best? >>>> >>>> Lets put it in the context: >>>> >>>> * Ergebnis: IRGENDWELCHE >>>> * Ergebnis: BELIEBIGES >>>> * Ergebnis: JEDES >>>> >>>> Did you try that feature? You should really try and see how it behaves I >>>> think. >>>> >>>> To me "Ergebnis: IRGENDWELCHE" it sounds unnatural. One can understand >>>> with >>>> a bit thought what that might mean. But it seems not so intuitive like >>>> the >>>> English word ANY. >>>> >>>> "Ergebnis: JEDES" seems to express the correct meaning and is easy to >>>> understand. Because whatever the result is, the steps in that block >>>> will be >>>> added before or after the scenario. In German: In *jedem* Fall werden >>>> Schritte vor oder nach dem Szenario hinzugefügt. >>>> >>>> Or concerning BELIEBIGES: Bei einem *beliebigen* Testergebnis werden >>>> Schritte vor oder nach dem Szenario hinzugefügt. Sound natural and easy >>>> to >>>> understand to me. >>>> >>>> But IRGENDWELCHE? Bei *irgendwelchen* Testergebnissen werden Schritte >>>> vor >>>> oder nach dem Szenario hinzugefügt? This sounds very strange to me. >>>> >>>> Concerning ISTQB, this is the definition of a failure: >>>> Deviation of the component or system from its expected delivery, >>>> service or >>>> result. >>>> See: http://www.istqb.org/downloads/viewcategory/20.html >>>> >>>> Failures is translated by ISTQB as "Fehlerwirkungen". >>>> See: http://www.software-tester.ch/PDF-Files/CT_Glossar_EN_DE_V22.pdf >>>> >>>> So it is not "Ausfall". You may say it is also not "Fehler". But >>>> "Fehlerwirkung is an artificial word originating from ISTQB. Noone I >>>> ever >>>> met (except ISTQB teachers) ever uses this word but instead says >>>> "Fehler". >>>> >>>> By the way, defect is translated as Fehlerzustand by ISTQB. This is >>>> also an >>>> artificial word which noone uses except ISTQB teachers. In Germany we >>>> call >>>> them: Bugs or simply Fehler, or much more academically and very seldom: >>>> Defekt. >>>> >>>> Besides that, ISTQB, although helpful to some degree in its basic >>>> teachings, >>>> I consider it to be non-agile in its full extent. I take only the good >>>> from >>>> it. >>>> >>>> >>>> On Tue, May 20, 2014 at 8:42 AM, Mauro Talevi < >>>> mauro.tal...@aquilonia.org> >>>> wrote: >>>> >>>>> So, what's the consensus then with the keywords? >>>>> >>>>> On 16/05/2014 18:42, Mauro Talevi wrote: >>>>> >>>>> I'll defer to whatever you guys decide is best. We can always change >>>>> it >>>>> later. >>>>> >>>>> On 15/05/2014 18:27, Mirko Friedenhagen wrote: >>>>> >>>>> Hans, >>>>&g
Re: [jbehave-user] Filtering works not as expected with a scenario containing an examples table
When will there be a beta-8 version of the 4.x branch containing this fix? I am asking because the examples for the JBehave article will need that, and the magazine is published on 2nd of July. On Wed, May 21, 2014 at 8:50 AM, Mauro Talevi wrote: > Sold! To the German-speaking gentleman at the back of the room :-) > > > On 20/05/2014 21:00, Mirko Friedenhagen wrote: > >> Hans, >> >> I stand corrected, in this case JEDES is a better translation for ANY. >> And make FAILURE FEHLER. >> Regards Mirko >> -- >> http://illegalstateexception.blogspot.com/ >> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) >> https://bitbucket.org/mfriedenhagen/ >> >> >> On Tue, May 20, 2014 at 10:14 AM, Hans Schwäbli >> wrote: >> >>> Mirko, I suppose you are a native German speaker like me, right? >>> >>> What is your message? That the current German translations for ANY and >>> FAILURE are the best? >>> >>> Lets put it in the context: >>> >>> * Ergebnis: IRGENDWELCHE >>> * Ergebnis: BELIEBIGES >>> * Ergebnis: JEDES >>> >>> Did you try that feature? You should really try and see how it behaves I >>> think. >>> >>> To me "Ergebnis: IRGENDWELCHE" it sounds unnatural. One can understand >>> with >>> a bit thought what that might mean. But it seems not so intuitive like >>> the >>> English word ANY. >>> >>> "Ergebnis: JEDES" seems to express the correct meaning and is easy to >>> understand. Because whatever the result is, the steps in that block will >>> be >>> added before or after the scenario. In German: In *jedem* Fall werden >>> Schritte vor oder nach dem Szenario hinzugefügt. >>> >>> Or concerning BELIEBIGES: Bei einem *beliebigen* Testergebnis werden >>> Schritte vor oder nach dem Szenario hinzugefügt. Sound natural and easy >>> to >>> understand to me. >>> >>> But IRGENDWELCHE? Bei *irgendwelchen* Testergebnissen werden Schritte vor >>> oder nach dem Szenario hinzugefügt? This sounds very strange to me. >>> >>> Concerning ISTQB, this is the definition of a failure: >>> Deviation of the component or system from its expected delivery, service >>> or >>> result. >>> See: http://www.istqb.org/downloads/viewcategory/20.html >>> >>> Failures is translated by ISTQB as "Fehlerwirkungen". >>> See: http://www.software-tester.ch/PDF-Files/CT_Glossar_EN_DE_V22.pdf >>> >>> So it is not "Ausfall". You may say it is also not "Fehler". But >>> "Fehlerwirkung is an artificial word originating from ISTQB. Noone I ever >>> met (except ISTQB teachers) ever uses this word but instead says >>> "Fehler". >>> >>> By the way, defect is translated as Fehlerzustand by ISTQB. This is also >>> an >>> artificial word which noone uses except ISTQB teachers. In Germany we >>> call >>> them: Bugs or simply Fehler, or much more academically and very seldom: >>> Defekt. >>> >>> Besides that, ISTQB, although helpful to some degree in its basic >>> teachings, >>> I consider it to be non-agile in its full extent. I take only the good >>> from >>> it. >>> >>> >>> On Tue, May 20, 2014 at 8:42 AM, Mauro Talevi < >>> mauro.tal...@aquilonia.org> >>> wrote: >>> >>>> So, what's the consensus then with the keywords? >>>> >>>> On 16/05/2014 18:42, Mauro Talevi wrote: >>>> >>>> I'll defer to whatever you guys decide is best. We can always change it >>>> later. >>>> >>>> On 15/05/2014 18:27, Mirko Friedenhagen wrote: >>>> >>>> Hans, >>>> >>>> I am not sure I agree :-). JEDES would be EVERY IMO. >>>> >>>> According to ISTQB FEHLER would be the DEFECT which causes a FAILURE >>>> (FEHLSCHLAG), which may lead to an AUSFALL (BREAKDOWN) of a server ;-) >>>> >>>> Am 15.05.2014 12:34 schrieb "Hans Schwäbli" >>>> : >>>> >>>>> I re-tested it and now it works. Thank you! >>>>> >>>>> However I did not use that feature in-depth so there might be some >>>>> other >>>>> isues. >>>>> >>>>> I wondered a bit about outcome ANY. It seems to be like the >>>&
Re: [jbehave-user] NPE at org.jbehave.core.configuration.Configuration.doDryRun(Boolean)
I attached a patch for this in this email (for 4.x branch).
On Wed, Jun 11, 2014 at 11:41 AM, Mauro Talevi
wrote:
> Lazy init may still have some teething issues. Please provide a patch.
>
>
> > On 11 Jun 2014, at 10:46, Hans Schwäbli
> wrote:
> >
> > Hello Mauro,
> >
> > today I had a NullPointerException at
> org.jbehave.core.configuration.Configuration.doDryRun(Boolean) with JBehave
> beta-6.
> >
> > It was because this.storyControls was null.
> >
> > Why don't you use storyControls().doDryRun(dryRun) instead of
> this.storyControls.doDryRun(dryRun)?
> >
> > Because the instance variable storyControls is lazy initialized in
> storyControls() method, so a NPE never could occur.
> >
> > My workaround now is first to call storyControls() method and after that
> doDryRun(...)
>
> -
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
diff --git
a/jbehave-core/src/main/java/org/jbehave/core/configuration/Configuration.java
b/jbehave-core/src/main/java/org/jbehave/core/configuration/Configuration.java
old mode 100755
new mode 100644
index 323d16f..12019fe
---
a/jbehave-core/src/main/java/org/jbehave/core/configuration/Configuration.java
+++
b/jbehave-core/src/main/java/org/jbehave/core/configuration/Configuration.java
@@ -175,7 +175,7 @@
}
public boolean dryRun() {
-return storyControls.dryRun();
+return storyControls().dryRun();
}
public StoryControls storyControls() {
@@ -317,7 +317,7 @@
}
public Configuration doDryRun(Boolean dryRun) {
-this.storyControls.doDryRun(dryRun);
+storyControls().doDryRun(dryRun);
return this;
}
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-user] Fwd: ContextView still works in 4.0-beta-7?
By the way: You can reproduce it with the same example which I mentioned in another issue: https://github.com/OttoDiesel/jbehave-selenium-example.git -- Forwarded message -- From: Hans Schwäbli Date: Mon, Jun 16, 2014 at 8:56 AM Subject: ContextView still works in 4.0-beta-7? To: user@jbehave.codehaus.org I changed a project from JBehave 3.9.2 to 4.0-beta-7. This made the context view disappear. I use the same code for applying the context view like I see in the JBehave examples today (org.jbehave.examples.core.CoreStories). Does the ContextView still work in JBehave 4.0-beta-7?
[jbehave-user] ContextView still works in 4.0-beta-7?
I changed a project from JBehave 3.9.2 to 4.0-beta-7. This made the context view disappear. I use the same code for applying the context view like I see in the JBehave examples today (org.jbehave.examples.core.CoreStories). Does the ContextView still work in JBehave 4.0-beta-7?
Re: [jbehave-user] Class which extends PerStoryWebDriverSteps is ignorerd if beforeStory() is overriden
https://github.com/OttoDiesel/jbehave-selenium-example.git See class example.steps.SeleniumWebDriverSteps. If you delete overriden methods beforeStory() and afterStory() then JBehave does not ignore SeleniumWebDriverSteps. You can see it because the browser is started. But if you leave these methods in the class, then the browser is not started because JBehave ignores SeleniumWebDriverSteps I suppose. I could reproduce this now at home with this. On Wed, Jun 11, 2014 at 11:42 AM, Mauro Talevi wrote: > Please provide a sample project to reproduce. > > > On 11 Jun 2014, at 11:26, Hans Schwäbli > wrote: > > > > Hello Mauro, > > > > I extend a class from org.jbehave.web.selenium.PerStoryWebDriverSteps > where I want to use the methode beforeStory() for some purpose. > > > > But when I do this, the extension is not known anymore to JBehave when I > start execution. > > > > This is very strange to me. Just overriding the beforeStory() method in > the class which extends PerStoryWebDriverSteps causes JBehave to ignore > that class completely. > > > > Maybe you can reproduce this or haven an idea how that occurs. > > > > I can provide you a example which you can download from Github, but I > haven't checked it in yet. > > > > By the way, I use JBehave 4 beta 6 and jbehave-web-selenium 3.5.5. > > - > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
[jbehave-user] Class which extends PerStoryWebDriverSteps is ignorerd if beforeStory() is overriden
Hello Mauro, I extend a class from org.jbehave.web.selenium.PerStoryWebDriverSteps where I want to use the methode beforeStory() for some purpose. But when I do this, the extension is not known anymore to JBehave when I start execution. This is very strange to me. Just overriding the beforeStory() method in the class which extends PerStoryWebDriverSteps causes JBehave to ignore that class completely. Maybe you can reproduce this or haven an idea how that occurs. I can provide you a example which you can download from Github, but I haven't checked it in yet. By the way, I use JBehave 4 beta 6 and jbehave-web-selenium 3.5.5.
[jbehave-user] NPE at org.jbehave.core.configuration.Configuration.doDryRun(Boolean)
Hello Mauro, today I had a NullPointerException at org.jbehave.core.configuration.Configuration.doDryRun(Boolean) with JBehave beta-6. It was because this.storyControls was null. Why don't you use storyControls().doDryRun(dryRun) instead of this.storyControls.doDryRun(dryRun)? Because the instance variable storyControls is lazy initialized in storyControls() method, so a NPE never could occur. My workaround now is first to call storyControls() method and after that doDryRun(...)
[jbehave-user] Interview is online at JAXenter
Hello German speaking JBehave users! I want to mention that there is an interview with Mauro Talevi now online: http://jaxenter.de/artikel/behavior-driven-development-mit-jbehave-interview-173871 In the upcoming Javamagazin edition there will be an article about JBehave. I think it will be published on the 2nd of July. It is a two part article, this will be part 1.
Re: [jbehave-user] JBehave Preferences
I see, no problem. That can be also solved with documentation specifical on what can be configured and what the defaults are I think. The default values could be also documented in Javadoc (I know, I don't use that very much too). On Tue, May 20, 2014 at 8:48 AM, Mauro Talevi wrote: > It's a design philosophy ... with its pros and cons. The risk of > creating a uber class is that you loose touch of what configuration is > relevant to what component. > > But in fact, the Configuration class allows you access to all the > different bits, the Controls, the Builders etc ... so that should be your > starting point. > > > On 19/05/2014 12:45, Hans Schwäbli wrote: > >> It seems a bit difficult to me to see which preferences can be set and >> what the defaults are. >> For example where is a class EmbedderControls which contains some of the >> preferences and defaults. >> There are more preferences like in ParameterControls, >> StoryReporterBuilder and other classes. >> What about putting them into a dedicated preferences class(es)? It would >> self document what preferences can be configured and it would be easier to >> find them. >> I am thinking about a class similiar like this: >> http://download.eclipse.org/technology/swtbot/helios/dev- >> build/apidocs/org/eclipse/swtbot/swt/finder/utils/SWTBotPreferences.html >> Maybe it could be several classes in the same preferences package >> containing all meaningful preferences to be set. The source could be a >> property file (like partly in IBM RFT) where the user could see them all in >> a central place and change them if he wishes. >> Maybe it is not a good idea, I don't know. I just have the impression >> that the preferences are a bit hard to find and spread across many places. >> > > > - > To unsubscribe from this list, please visit: > >http://xircles.codehaus.org/manage_email > > >
Re: [jbehave-user] Filtering works not as expected with a scenario containing an examples table
Mirko, I suppose you are a native German speaker like me, right? What is your message? That the current German translations for ANY and FAILURE are the best? Lets put it in the context: * Ergebnis: IRGENDWELCHE * Ergebnis: BELIEBIGES * Ergebnis: JEDES Did you try that feature? You should really try and see how it behaves I think. To me "Ergebnis: IRGENDWELCHE" it sounds unnatural. One can understand with a bit thought what that might mean. But it seems not so intuitive like the English word ANY. "Ergebnis: JEDES" seems to express the correct meaning and is easy to understand. Because whatever the result is, the steps in that block will be added before or after the scenario. In German: In *jedem* Fall werden Schritte vor oder nach dem Szenario hinzugefügt. Or concerning BELIEBIGES: Bei einem *beliebigen* Testergebnis werden Schritte vor oder nach dem Szenario hinzugefügt. Sound natural and easy to understand to me. But IRGENDWELCHE? Bei *irgendwelchen* Testergebnissen werden Schritte vor oder nach dem Szenario hinzugefügt? This sounds very strange to me. Concerning ISTQB, this is the definition of a failure: Deviation of the component or system from its expected delivery, service or result. See: http://www.istqb.org/downloads/viewcategory/20.html Failures is translated by ISTQB as "Fehlerwirkungen". See: http://www.software-tester.ch/PDF-Files/CT_Glossar_EN_DE_V22.pdf So it is not "Ausfall". You may say it is also not "Fehler". But "Fehlerwirkung is an artificial word originating from ISTQB. Noone I ever met (except ISTQB teachers) ever uses this word but instead says "Fehler". By the way, defect is translated as Fehlerzustand by ISTQB. This is also an artificial word which noone uses except ISTQB teachers. In Germany we call them: Bugs or simply Fehler, or much more academically and very seldom: Defekt. Besides that, ISTQB, although helpful to some degree in its basic teachings, I consider it to be non-agile in its full extent. I take only the good from it. On Tue, May 20, 2014 at 8:42 AM, Mauro Talevi wrote: > So, what's the consensus then with the keywords? > > On 16/05/2014 18:42, Mauro Talevi wrote: > > I'll defer to whatever you guys decide is best. We can always change it > later. > > On 15/05/2014 18:27, Mirko Friedenhagen wrote: > > Hans, > > I am not sure I agree :-). JEDES would be EVERY IMO. > > According to ISTQB FEHLER would be the DEFECT which causes a FAILURE > (FEHLSCHLAG), which may lead to an AUSFALL (BREAKDOWN) of a server ;-) > Am 15.05.2014 12:34 schrieb "Hans Schwäbli" >: > >> I re-tested it and now it works. Thank you! >> >> However I did not use that feature in-depth so there might be some other >> isues. >> >> I wondered a bit about outcome ANY. It seems to be like the finally-block >> in Java. The German translation IRGENDWELCHE is maybe not the best for ANY. >> Ergebnis: "BELIEBIGES" or "JEDES" seems to be better to me. >> >> And Ergebnis: "AUSFALL" seems not to be the best translation too. I >> think better would be Ergebnis "FEHLER". >> >> Maybe some other German speaking guys can share their opinions about a >> translation for ANY and FAILURE? >> >> >> On Thu, May 15, 2014 at 12:08 AM, Mauro Talevi < >> mauro.tal...@aquilonia.org> wrote: >> >>> There was an issue with parsing with non-EN locales. Now fixed, try >>> again with latest head. >>> >>> >>> On 14/05/2014 17:35, Hans Schwäbli wrote: >>> >>> I quickly tested the lifecycle. >>> >>> Story: >>> >>> Lebenszyklus: >>> Vorher: >>> Gegeben im Lager sind 100 T-Shirts >>> Nach: >>> Ergebnis: ERFOLG >>> Gegeben im Lager sind 200 T-Shirts >>> Ergebnis: IRGENDWELCHE >>> Gegeben im Lager sind 300 T-Shirts >>> Ergebnis: AUSFALL >>> Gegeben im Lager sind 400 T-Shirts >>> Szenario: Versandkosten fallen weg >>> Wenn ein Kunde 20 T-Shirts bestellt >>> Dann betragen die Versandkosten 7,5 Euro >>> Result is: >>> >>> Lebenszyklus: >>> Vorher: >>> Gegeben im Lager sind 100 T-Shirts >>> Nach: >>> Ergebnis: IRGENDWELCHE >>> Gegeben im Lager sind 200 T-Shirts >>> Gegeben im Lager sind 300 T-Shirts >>> Gegeben im Lager sind 400 T-Shirts >>> >>> Szenario: Versandkosten fallen weg >>> Gegeben im Lager sind 100 T-Shirts >>> Wenn ein Kunde 20 T-Shirts bestellt >>> Dann betragen die Versandkosten 7,5 Euro >>> Gegeben im Lager sind 200 T-Shirts >>> Gegeben im Lager sind 300 T-S
[jbehave-user] Fwd: saveScreenshotTo(String) returns boolean
I seen that it originates from Selenium in the end: org.jbehave.web.selenium.WebDriverProvider.saveScreenshotTo(String) But I think I can achieve what I want anyway. You can forget that topic I think. -- Forwarded message -- From: Hans Schwäbli Date: Mon, May 19, 2014 at 1:06 PM Subject: saveScreenshotTo(String) returns boolean To: user@jbehave.codehaus.org This method returns a boolean: org.jbehave.web.selenium.DelegatingWebDriverProvider.saveScreenshotTo(String) What if it would return a File instead if it succeeds and null if it does not succeed? Then the return value would contain more information and thus it would open up more possibilities. I then could more easily upload all these screenshots to a HP Quality test run. Currently it is hard to do this because all file names are like failed-scenario-1ab3b70f-f6d8-4dc8-a257-87a8c6a26276.png, I don't know which one belongs to which story or execution. But if saveScreenshotTo(String) would return a File I could remember them and upload it after execution finished. Well, its more nice to have, I know.
[jbehave-user] saveScreenshotTo(String) returns boolean
This method returns a boolean: org.jbehave.web.selenium.DelegatingWebDriverProvider.saveScreenshotTo(String) What if it would return a File instead if it succeeds and null if it does not succeed? Then the return value would contain more information and thus it would open up more possibilities. I then could more easily upload all these screenshots to a HP Quality test run. Currently it is hard to do this because all file names are like failed-scenario-1ab3b70f-f6d8-4dc8-a257-87a8c6a26276.png, I don't know which one belongs to which story or execution. But if saveScreenshotTo(String) would return a File I could remember them and upload it after execution finished. Well, its more nice to have, I know.
[jbehave-user] JBehave Preferences
It seems a bit difficult to me to see which preferences can be set and what the defaults are. For example where is a class EmbedderControls which contains some of the preferences and defaults. There are more preferences like in ParameterControls, StoryReporterBuilder and other classes. What about putting them into a dedicated preferences class(es)? It would self document what preferences can be configured and it would be easier to find them. I am thinking about a class similiar like this: http://download.eclipse.org/technology/swtbot/helios/dev-build/apidocs/org/eclipse/swtbot/swt/finder/utils/SWTBotPreferences.html Maybe it could be several classes in the same preferences package containing all meaningful preferences to be set. The source could be a property file (like partly in IBM RFT) where the user could see them all in a central place and change them if he wishes. Maybe it is not a good idea, I don't know. I just have the impression that the preferences are a bit hard to find and spread across many places.
Re: [jbehave-user] Filtering works not as expected with a scenario containing an examples table
I re-tested it and now it works. Thank you! However I did not use that feature in-depth so there might be some other isues. I wondered a bit about outcome ANY. It seems to be like the finally-block in Java. The German translation IRGENDWELCHE is maybe not the best for ANY. Ergebnis: "BELIEBIGES" or "JEDES" seems to be better to me. And Ergebnis: "AUSFALL" seems not to be the best translation too. I think better would be Ergebnis "FEHLER". Maybe some other German speaking guys can share their opinions about a translation for ANY and FAILURE? On Thu, May 15, 2014 at 12:08 AM, Mauro Talevi wrote: > There was an issue with parsing with non-EN locales. Now fixed, try > again with latest head. > > > On 14/05/2014 17:35, Hans Schwäbli wrote: > > I quickly tested the lifecycle. > > Story: > > Lebenszyklus: > Vorher: > Gegeben im Lager sind 100 T-Shirts > Nach: > Ergebnis: ERFOLG > Gegeben im Lager sind 200 T-Shirts > Ergebnis: IRGENDWELCHE > Gegeben im Lager sind 300 T-Shirts > Ergebnis: AUSFALL > Gegeben im Lager sind 400 T-Shirts > Szenario: Versandkosten fallen weg > Wenn ein Kunde 20 T-Shirts bestellt > Dann betragen die Versandkosten 7,5 Euro > Result is: > > Lebenszyklus: > Vorher: > Gegeben im Lager sind 100 T-Shirts > Nach: > Ergebnis: IRGENDWELCHE > Gegeben im Lager sind 200 T-Shirts > Gegeben im Lager sind 300 T-Shirts > Gegeben im Lager sind 400 T-Shirts > > Szenario: Versandkosten fallen weg > Gegeben im Lager sind 100 T-Shirts > Wenn ein Kunde 20 T-Shirts bestellt > Dann betragen die Versandkosten 7,5 Euro > Gegeben im Lager sind 200 T-Shirts > Gegeben im Lager sind 300 T-Shirts > Gegeben im Lager sind 400 T-Shirts > > It does not work as I expect it since it executes all three after steps > although it should only execute the one for "Ergebnis: ERFOLG" (Outcome: > SUCCESS). > > On Friday or next week I can test that a bit more thoroughly. > > > On Tue, May 13, 2014 at 8:00 PM, Mauro Talevi > wrote: > >> Cool, we'll push out new beta soon. >> >> Can you also take the Lifecycle After upon outcome functionality for a >> spin while you're at it? >> >> On 13/05/2014 13:42, Hans Schwäbli wrote: >> >> I mixed up snapshot versions with beta-versions, sorry. >> >> I tried now the snapshot version and it works now as expected concerning >> the problem with the examples table. >> >> Thank you! >> >> But there is a problem with comments. I will write a posting just on that. >> >> >> On Thu, May 8, 2014 at 10:51 AM, Mauro Talevi > > wrote: >> >>> No, a new beta has not been deployed yet. In the meantime, you can >>> use the latest 3.9.x or build the 4.0 snapshot from source. >>> >>> On 8 May 2014, at 08:59, Hans Schwäbli >>> wrote: >>> >>> Thank you! Is it also deployed? >>> I did not find it here: >>> https://nexus.codehaus.org/content/groups/public/org/jbehave/jbehave-core/4.0-beta-7/ >>> The last snapshot there is from 2nd of May. >>> The same snapshot date is on: >>> http://mvnrepository.com/artifact/org.jbehave/jbehave-maven-plugin/4.0-beta-7/ >>> >>> >>> On Wed, May 7, 2014 at 11:25 PM, Mauro Talevi < >>> mauro.tal...@aquilonia.org> wrote: >>> >>>> This issue is now fixed in head of 4.x branch. It did not apply to >>>> 3.x. >>>> >>>> >>>> On 07/05/2014 10:55, Hans Schwäbli wrote: >>>> >>>> I created such an example for jbehave-core now and attached it to >>>> this posting. I still cannot work on a clone the Github project because of >>>> company restrictions (I haven't yet received an answer why it is not >>>> working inside the company proxy). >>>> >>>> In case the mailing list does not support attachments I have also sent >>>> them directly to Mauro. >>>> >>>> To reproduce it you will need this in the Maven pom.xml: >>>> >>>> >>>> >>>> >>>> *+component order -skip* >>>> >>>> >>>> >>>> >>>> On Wed, May 7, 2014 at 11:03 AM, Hans Schwäbli < >>>> bugs.need.love@gmail.com> wrote: >>>> >>>>> I committed it here: >>>>> https://github.com/OttoDiesel/jbehave-shop-example.git >>>>> >>>>> I will add such a scenario to the core examples. Until then you could >>>>> use
Re: [jbehave-user] Filtering works not as expected with a scenario containing an examples table
I quickly tested the lifecycle. Story: Lebenszyklus: Vorher: Gegeben im Lager sind 100 T-Shirts Nach: Ergebnis: ERFOLG Gegeben im Lager sind 200 T-Shirts Ergebnis: IRGENDWELCHE Gegeben im Lager sind 300 T-Shirts Ergebnis: AUSFALL Gegeben im Lager sind 400 T-Shirts Szenario: Versandkosten fallen weg Wenn ein Kunde 20 T-Shirts bestellt Dann betragen die Versandkosten 7,5 Euro Result is: Lebenszyklus: Vorher: Gegeben im Lager sind 100 T-Shirts Nach: Ergebnis: IRGENDWELCHE Gegeben im Lager sind 200 T-Shirts Gegeben im Lager sind 300 T-Shirts Gegeben im Lager sind 400 T-Shirts Szenario: Versandkosten fallen weg Gegeben im Lager sind 100 T-Shirts Wenn ein Kunde 20 T-Shirts bestellt Dann betragen die Versandkosten 7,5 Euro Gegeben im Lager sind 200 T-Shirts Gegeben im Lager sind 300 T-Shirts Gegeben im Lager sind 400 T-Shirts It does not work as I expect it since it executes all three after steps although it should only execute the one for "Ergebnis: ERFOLG" (Outcome: SUCCESS). On Friday or next week I can test that a bit more thoroughly. On Tue, May 13, 2014 at 8:00 PM, Mauro Talevi wrote: > Cool, we'll push out new beta soon. > > Can you also take the Lifecycle After upon outcome functionality for a > spin while you're at it? > > On 13/05/2014 13:42, Hans Schwäbli wrote: > > I mixed up snapshot versions with beta-versions, sorry. > > I tried now the snapshot version and it works now as expected concerning > the problem with the examples table. > > Thank you! > > But there is a problem with comments. I will write a posting just on that. > > > On Thu, May 8, 2014 at 10:51 AM, Mauro Talevi > wrote: > >> No, a new beta has not been deployed yet. In the meantime, you can >> use the latest 3.9.x or build the 4.0 snapshot from source. >> >> On 8 May 2014, at 08:59, Hans Schwäbli >> wrote: >> >> Thank you! Is it also deployed? >> I did not find it here: >> https://nexus.codehaus.org/content/groups/public/org/jbehave/jbehave-core/4.0-beta-7/ >> The last snapshot there is from 2nd of May. >> The same snapshot date is on: >> http://mvnrepository.com/artifact/org.jbehave/jbehave-maven-plugin/4.0-beta-7/ >> >> >> On Wed, May 7, 2014 at 11:25 PM, Mauro Talevi > > wrote: >> >>> This issue is now fixed in head of 4.x branch. It did not apply to >>> 3.x. >>> >>> >>> On 07/05/2014 10:55, Hans Schwäbli wrote: >>> >>> I created such an example for jbehave-core now and attached it to >>> this posting. I still cannot work on a clone the Github project because of >>> company restrictions (I haven't yet received an answer why it is not >>> working inside the company proxy). >>> >>> In case the mailing list does not support attachments I have also sent >>> them directly to Mauro. >>> >>> To reproduce it you will need this in the Maven pom.xml: >>> >>> >>> >>> >>> *+component order -skip* >>> >>> >>> >>> >>> On Wed, May 7, 2014 at 11:03 AM, Hans Schwäbli < >>> bugs.need.love@gmail.com> wrote: >>> >>>> I committed it here: >>>> https://github.com/OttoDiesel/jbehave-shop-example.git >>>> >>>> I will add such a scenario to the core examples. Until then you could >>>> use that other example if you like. It is the example for the article on >>>> JBehave by the way. >>>> >>>> >>>> On Tue, May 6, 2014 at 3:04 PM, Mauro Talevi < >>>> mauro.tal...@aquilonia.org> wrote: >>>> >>>>> Yes, it looks likely to be unrelated to given stories and such. >>>>> >>>>> Could you please add a scenario reproducing the behaviour to the >>>>> meta_filtering.story in the core examples (preferably in English)? >>>>> >>>>> Does it work with 3.x? >>>>> >>>>> On 06/05/2014 11:34, Hans Schwäbli wrote: >>>>> >>>>> I already use StoryControls.doIgnoreMetaFiltersIfGivenStory(true). >>>>> And I removed the given story in the story. >>>>> >>>>> But the result is the same. >>>>> >>>>> Maybe tomorrow I can commit the whole project, so that you can >>>>> reproduce it. >>>>> >>>>> >>>>> On Tue, May 6, 2014 at 11:00 AM, Stephen de Vries >>>> > wrote: >>>>> >>>>>> >>>>>> On 6 May 2014, at 10:51, Hans Schwäbli >>>>>> wrote: >>>>>> >>>>>> I have the example story, see below. It runs not as expected when >>>>>> filtering by: +Komponente Bestellung -Skip >>>>>> >>>>>> VorgegebeneStories: >>>>>> shop/stories/Login.story >>>>>> >>>>>> >>>>>> My guess is that the given story doesn’t have the same meta-tags. >>>>>> Fix is to set: StoryControls.doIgnoreMetaFiltersIfGivenStory(true) >>>>>> >>>>>> See: http://jira.codehaus.org/browse/JBEHAVE-789 >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> - >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >>> >> > >
Re: [jbehave-user] Comment lines are not parsed correctly in 4.x as it seems
Great! I created it: http://jira.codehaus.org/i#browse/JBEHAVE-1016
On Wed, May 14, 2014 at 9:12 AM, Mauro Talevi wrote:
> Yes, editor and core use two different parsers.
>
> We can align the two. We can support no space after the comment. Please
> raise a JIRA for this.
>
>
> On 14/05/2014 09:10, Hans Schwäbli wrote:
>
> I will do that, thank you.
>
> The story editor displays that line as a comment line, painting it green.
> It does not require a space after !-- for the story editor to detect it as
> a comment line. It is the same with some other keywords in the story
> editor, for example I can start a line with Scenario:blabla and the story
> editor recognizes it as a scenario.
>
> Usually comment keywords don't include a space (XML, SQL, Javadoc etc.) So
> it is contra intuitive in a way.
>
> It is contra intuitive because of that and because the story editor
> recognizes some of the keywords without having to add a space, but the
> execution does not recognize them as such.
>
> Does that make sense?
>
>
> 2014-05-13 19:43 GMT+02:00 Mauro Talevi :
>
>> You need a space after the !-- (the comment keyword is treated like at
>> any other keyword, thus separated by a space from the comment)
>>
>>
>> On 13/05/2014 13:51, Hans Schwäbli wrote:
>>
>> In 4.x branch comments doen't seem to be allowed where they used to be
>> allowed in version 3.x.
>>
>> Lets take this example (please ingore German language, it has nothing to
>> do with the problem):
>>
>> Szenario: Kleine Menge wird bestellt
>> Gegeben im Lager sind 300 T-Shirts
>> Wenn ein Kunde 5 T-Shirts bestellt
>> !--TODO: Gesamtbestellwert könnte auch noch geprüft werden.
>> Dann ist die Bestellung auf Lager
>> Und gilt eine Ermässigung von 0 Prozent
>> Und kostet ein T-Shirt pro Stück 10 Euro
>> Und betragen die Versandkosten 7,50 Euro
>> Und ist der Bestellwert 57,50 Euro
>> That causes this execution failure:
>>
>> Szenario: Kleine Menge wird bestellt
>> Gegeben im Lager sind 300 T-Shirts
>> Wenn ein Kunde 5 T-Shirts bestellt
>> !--TODO: Gesamtbestellwert könnte auch noch geprüft werden. (AUSSTEHEND)
>> Dann ist die Bestellung auf Lager (NICHT AUSGEFÜHRT)
>> Und gilt eine Ermässigung von 0 Prozent (NICHT AUSGEFÜHRT)
>> Und kostet ein T-Shirt pro Stück 10 Euro (NICHT AUSGEFÜHRT)
>> Und betragen die Versandkosten 7,50 Euro (NICHT AUSGEFÜHRT)
>> Und ist der Bestellwert 57,50 Euro (NICHT AUSGEFÜHRT)
>> @When("ein Kunde 5 T-Shirts bestellt\r\n!--TODO: Gesamtbestellwert
>> k\u00F6nnte auch noch gepr\u00FCft werden.")
>> @Pending
>> public void
>> whenEinKunde5TShirtsBestelltTODOGesamtbestellwertKönnteAuchNochGeprüftWerden()
>> {
>> // AUSSTEHEND
>> }
>>
>> You can reproduce that easily if you place a comment line between steps
>> in a scenario.
>>
>> I suggest that you "pollute" your jbehave-core example stories with
>> comments on all different places (starting with !-- and |-- or even a line
>> including both, be nasty) so that you have a regression test for the story
>> parser concerning comment lines.
>>
>>
>>
>
>
Re: [jbehave-user] Comment lines are not parsed correctly in 4.x as it seems
I will do that, thank you.
The story editor displays that line as a comment line, painting it green.
It does not require a space after !-- for the story editor to detect it as
a comment line. It is the same with some other keywords in the story
editor, for example I can start a line with Scenario:blabla and the story
editor recognizes it as a scenario.
Usually comment keywords don't include a space (XML, SQL, Javadoc etc.) So
it is contra intuitive in a way.
It is contra intuitive because of that and because the story editor
recognizes some of the keywords without having to add a space, but the
execution does not recognize them as such.
Does that make sense?
2014-05-13 19:43 GMT+02:00 Mauro Talevi :
> You need a space after the !-- (the comment keyword is treated like at
> any other keyword, thus separated by a space from the comment)
>
>
> On 13/05/2014 13:51, Hans Schwäbli wrote:
>
> In 4.x branch comments doen't seem to be allowed where they used to be
> allowed in version 3.x.
>
> Lets take this example (please ingore German language, it has nothing to
> do with the problem):
>
> Szenario: Kleine Menge wird bestellt
> Gegeben im Lager sind 300 T-Shirts
> Wenn ein Kunde 5 T-Shirts bestellt
> !--TODO: Gesamtbestellwert könnte auch noch geprüft werden.
> Dann ist die Bestellung auf Lager
> Und gilt eine Ermässigung von 0 Prozent
> Und kostet ein T-Shirt pro Stück 10 Euro
> Und betragen die Versandkosten 7,50 Euro
> Und ist der Bestellwert 57,50 Euro
> That causes this execution failure:
>
> Szenario: Kleine Menge wird bestellt
> Gegeben im Lager sind 300 T-Shirts
> Wenn ein Kunde 5 T-Shirts bestellt
> !--TODO: Gesamtbestellwert könnte auch noch geprüft werden. (AUSSTEHEND)
> Dann ist die Bestellung auf Lager (NICHT AUSGEFÜHRT)
> Und gilt eine Ermässigung von 0 Prozent (NICHT AUSGEFÜHRT)
> Und kostet ein T-Shirt pro Stück 10 Euro (NICHT AUSGEFÜHRT)
> Und betragen die Versandkosten 7,50 Euro (NICHT AUSGEFÜHRT)
> Und ist der Bestellwert 57,50 Euro (NICHT AUSGEFÜHRT)
> @When("ein Kunde 5 T-Shirts bestellt\r\n!--TODO: Gesamtbestellwert
> k\u00F6nnte auch noch gepr\u00FCft werden.")
> @Pending
> public void
> whenEinKunde5TShirtsBestelltTODOGesamtbestellwertKönnteAuchNochGeprüftWerden()
> {
> // AUSSTEHEND
> }
>
> You can reproduce that easily if you place a comment line between steps in
> a scenario.
>
> I suggest that you "pollute" your jbehave-core example stories with
> comments on all different places (starting with !-- and |-- or even a line
> including both, be nasty) so that you have a regression test for the story
> parser concerning comment lines.
>
>
>
[jbehave-user] Comment lines are not parsed correctly in 4.x as it seems
In 4.x branch comments doen't seem to be allowed where they used to be
allowed in version 3.x.
Lets take this example (please ingore German language, it has nothing to do
with the problem):
Szenario: Kleine Menge wird bestellt
Gegeben im Lager sind 300 T-Shirts
Wenn ein Kunde 5 T-Shirts bestellt
!--TODO: Gesamtbestellwert könnte auch noch geprüft werden.
Dann ist die Bestellung auf Lager
Und gilt eine Ermässigung von 0 Prozent
Und kostet ein T-Shirt pro Stück 10 Euro
Und betragen die Versandkosten 7,50 Euro
Und ist der Bestellwert 57,50 Euro
That causes this execution failure:
Szenario: Kleine Menge wird bestellt
Gegeben im Lager sind 300 T-Shirts
Wenn ein Kunde 5 T-Shirts bestellt
!--TODO: Gesamtbestellwert könnte auch noch geprüft werden. (AUSSTEHEND)
Dann ist die Bestellung auf Lager (NICHT AUSGEFÜHRT)
Und gilt eine Ermässigung von 0 Prozent (NICHT AUSGEFÜHRT)
Und kostet ein T-Shirt pro Stück 10 Euro (NICHT AUSGEFÜHRT)
Und betragen die Versandkosten 7,50 Euro (NICHT AUSGEFÜHRT)
Und ist der Bestellwert 57,50 Euro (NICHT AUSGEFÜHRT)
@When("ein Kunde 5 T-Shirts bestellt\r\n!--TODO: Gesamtbestellwert
k\u00F6nnte auch noch gepr\u00FCft werden.")
@Pending
public void
whenEinKunde5TShirtsBestelltTODOGesamtbestellwertKönnteAuchNochGeprüftWerden()
{
// AUSSTEHEND
}
You can reproduce that easily if you place a comment line between steps in
a scenario.
I suggest that you "pollute" your jbehave-core example stories with
comments on all different places (starting with !-- and |-- or even a line
including both, be nasty) so that you have a regression test for the story
parser concerning comment lines.
Re: [jbehave-user] Filtering works not as expected with a scenario containing an examples table
I mixed up snapshot versions with beta-versions, sorry. I tried now the snapshot version and it works now as expected concerning the problem with the examples table. Thank you! But there is a problem with comments. I will write a posting just on that. On Thu, May 8, 2014 at 10:51 AM, Mauro Talevi wrote: > No, a new beta has not been deployed yet. In the meantime, you can use > the latest 3.9.x or build the 4.0 snapshot from source. > > On 8 May 2014, at 08:59, Hans Schwäbli > wrote: > > Thank you! Is it also deployed? > I did not find it here: > https://nexus.codehaus.org/content/groups/public/org/jbehave/jbehave-core/4.0-beta-7/ > The last snapshot there is from 2nd of May. > The same snapshot date is on: > http://mvnrepository.com/artifact/org.jbehave/jbehave-maven-plugin/4.0-beta-7/ > > > On Wed, May 7, 2014 at 11:25 PM, Mauro Talevi > wrote: > >> This issue is now fixed in head of 4.x branch. It did not apply to >> 3.x. >> >> >> On 07/05/2014 10:55, Hans Schwäbli wrote: >> >> I created such an example for jbehave-core now and attached it to this >> posting. I still cannot work on a clone the Github project because of >> company restrictions (I haven't yet received an answer why it is not >> working inside the company proxy). >> >> In case the mailing list does not support attachments I have also sent >> them directly to Mauro. >> >> To reproduce it you will need this in the Maven pom.xml: >> >> >> >> >> *+component order -skip* >> >> >> >> >> On Wed, May 7, 2014 at 11:03 AM, Hans Schwäbli < >> bugs.need.love@gmail.com> wrote: >> >>> I committed it here: >>> https://github.com/OttoDiesel/jbehave-shop-example.git >>> >>> I will add such a scenario to the core examples. Until then you could >>> use that other example if you like. It is the example for the article on >>> JBehave by the way. >>> >>> >>> On Tue, May 6, 2014 at 3:04 PM, Mauro Talevi >> > wrote: >>> >>>> Yes, it looks likely to be unrelated to given stories and such. >>>> >>>> Could you please add a scenario reproducing the behaviour to the >>>> meta_filtering.story in the core examples (preferably in English)? >>>> >>>> Does it work with 3.x? >>>> >>>> On 06/05/2014 11:34, Hans Schwäbli wrote: >>>> >>>> I already use StoryControls.doIgnoreMetaFiltersIfGivenStory(true). >>>> And I removed the given story in the story. >>>> >>>> But the result is the same. >>>> >>>> Maybe tomorrow I can commit the whole project, so that you can >>>> reproduce it. >>>> >>>> >>>> On Tue, May 6, 2014 at 11:00 AM, Stephen de Vries >>>> wrote: >>>> >>>>> >>>>> On 6 May 2014, at 10:51, Hans Schwäbli >>>>> wrote: >>>>> >>>>> I have the example story, see below. It runs not as expected when >>>>> filtering by: +Komponente Bestellung -Skip >>>>> >>>>> VorgegebeneStories: >>>>> shop/stories/Login.story >>>>> >>>>> >>>>> My guess is that the given story doesn’t have the same meta-tags. >>>>> Fix is to set: StoryControls.doIgnoreMetaFiltersIfGivenStory(true) >>>>> >>>>> See: http://jira.codehaus.org/browse/JBEHAVE-789 >>>>> >>>>> >>>> >>>> >>> >> >> >> - >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >
Re: [jbehave-user] Filtering works not as expected with a scenario containing an examples table
Thank you! Is it also deployed? I did not find it here: https://nexus.codehaus.org/content/groups/public/org/jbehave/jbehave-core/4.0-beta-7/ The last snapshot there is from 2nd of May. The same snapshot date is on: http://mvnrepository.com/artifact/org.jbehave/jbehave-maven-plugin/4.0-beta-7/ On Wed, May 7, 2014 at 11:25 PM, Mauro Talevi wrote: > This issue is now fixed in head of 4.x branch. It did not apply to 3.x. > > > On 07/05/2014 10:55, Hans Schwäbli wrote: > > I created such an example for jbehave-core now and attached it to this > posting. I still cannot work on a clone the Github project because of > company restrictions (I haven't yet received an answer why it is not > working inside the company proxy). > > In case the mailing list does not support attachments I have also sent > them directly to Mauro. > > To reproduce it you will need this in the Maven pom.xml: > > > > > *+component order -skip* > > > > > On Wed, May 7, 2014 at 11:03 AM, Hans Schwäbli < > bugs.need.love@gmail.com> wrote: > >> I committed it here: >> https://github.com/OttoDiesel/jbehave-shop-example.git >> >> I will add such a scenario to the core examples. Until then you could use >> that other example if you like. It is the example for the article on >> JBehave by the way. >> >> >> On Tue, May 6, 2014 at 3:04 PM, Mauro Talevi >> wrote: >> >>> Yes, it looks likely to be unrelated to given stories and such. >>> >>> Could you please add a scenario reproducing the behaviour to the >>> meta_filtering.story in the core examples (preferably in English)? >>> >>> Does it work with 3.x? >>> >>> On 06/05/2014 11:34, Hans Schwäbli wrote: >>> >>> I already use StoryControls.doIgnoreMetaFiltersIfGivenStory(true). And >>> I removed the given story in the story. >>> >>> But the result is the same. >>> >>> Maybe tomorrow I can commit the whole project, so that you can reproduce >>> it. >>> >>> >>> On Tue, May 6, 2014 at 11:00 AM, Stephen de Vries >>> wrote: >>> >>>> >>>> On 6 May 2014, at 10:51, Hans Schwäbli >>>> wrote: >>>> >>>> I have the example story, see below. It runs not as expected when >>>> filtering by: +Komponente Bestellung -Skip >>>> >>>> VorgegebeneStories: >>>> shop/stories/Login.story >>>> >>>> >>>> My guess is that the given story doesn’t have the same meta-tags. >>>> Fix is to set: StoryControls.doIgnoreMetaFiltersIfGivenStory(true) >>>> >>>> See: http://jira.codehaus.org/browse/JBEHAVE-789 >>>> >>>> >>> >>> >> > > > - > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
Re: [jbehave-user] Filtering works not as expected with a scenario containing an examples table
I created such an example for jbehave-core now and attached it to this posting. I still cannot work on a clone the Github project because of company restrictions (I haven't yet received an answer why it is not working inside the company proxy). In case the mailing list does not support attachments I have also sent them directly to Mauro. To reproduce it you will need this in the Maven pom.xml: *+component order -skip* On Wed, May 7, 2014 at 11:03 AM, Hans Schwäbli wrote: > I committed it here: > https://github.com/OttoDiesel/jbehave-shop-example.git > > I will add such a scenario to the core examples. Until then you could use > that other example if you like. It is the example for the article on > JBehave by the way. > > > On Tue, May 6, 2014 at 3:04 PM, Mauro Talevi > wrote: > >> Yes, it looks likely to be unrelated to given stories and such. >> >> Could you please add a scenario reproducing the behaviour to the >> meta_filtering.story in the core examples (preferably in English)? >> >> Does it work with 3.x? >> >> On 06/05/2014 11:34, Hans Schwäbli wrote: >> >> I already use StoryControls.doIgnoreMetaFiltersIfGivenStory(true). And >> I removed the given story in the story. >> >> But the result is the same. >> >> Maybe tomorrow I can commit the whole project, so that you can reproduce >> it. >> >> >> On Tue, May 6, 2014 at 11:00 AM, Stephen de Vries wrote: >> >>> >>> On 6 May 2014, at 10:51, Hans Schwäbli >>> wrote: >>> >>> I have the example story, see below. It runs not as expected when >>> filtering by: +Komponente Bestellung -Skip >>> >>> VorgegebeneStories: >>> shop/stories/Login.story >>> >>> >>> My guess is that the given story doesn’t have the same meta-tags. Fix >>> is to set: StoryControls.doIgnoreMetaFiltersIfGivenStory(true) >>> >>> See: http://jira.codehaus.org/browse/JBEHAVE-789 >>> >>> >> >> > For orders it has to be checked whether discounts apply. In addition, no shipping costs will be calculated with a high value of goods. Meta: @component order Narrative: In order to create quotes and invoices As a agend in the sales department I want to take discounts into account Scenario: Discount limits are reached !--TODO: Total value could also be examined. When a customer orders T-Shirts Then the discount is percent And the price for one T-Shirt is Euro Examples: |--||-| |amount|discount|price| |--||-| |49|0 |10 | |50|10 |9| |99|10 |9| |100 |20 |8| |--||-| OderSteps.java Description: Binary data ShopStories.java Description: Binary data - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [jbehave-user] Filtering works not as expected with a scenario containing an examples table
I committed it here: https://github.com/OttoDiesel/jbehave-shop-example.git I will add such a scenario to the core examples. Until then you could use that other example if you like. It is the example for the article on JBehave by the way. On Tue, May 6, 2014 at 3:04 PM, Mauro Talevi wrote: > Yes, it looks likely to be unrelated to given stories and such. > > Could you please add a scenario reproducing the behaviour to the > meta_filtering.story in the core examples (preferably in English)? > > Does it work with 3.x? > > On 06/05/2014 11:34, Hans Schwäbli wrote: > > I already use StoryControls.doIgnoreMetaFiltersIfGivenStory(true). And I > removed the given story in the story. > > But the result is the same. > > Maybe tomorrow I can commit the whole project, so that you can reproduce > it. > > > On Tue, May 6, 2014 at 11:00 AM, Stephen de Vries wrote: > >> >> On 6 May 2014, at 10:51, Hans Schwäbli >> wrote: >> >> I have the example story, see below. It runs not as expected when >> filtering by: +Komponente Bestellung -Skip >> >> VorgegebeneStories: >> shop/stories/Login.story >> >> >> My guess is that the given story doesn’t have the same meta-tags. Fix >> is to set: StoryControls.doIgnoreMetaFiltersIfGivenStory(true) >> >> See: http://jira.codehaus.org/browse/JBEHAVE-789 >> >> > >
Re: [jbehave-user] Using regular expressions as a meta info value is not supported as it seems
Thank you. I will try that. On Tue, May 6, 2014 at 10:08 AM, Mauro Talevi wrote: > Groovy meta matcher supports regex: > > http://jbehave.org/reference/stable/meta-filtering.html > > > On 06/05/2014 08:46, Hans Schwäbli wrote: > > I tried to use a regular expression as a meta info value: +component > sales|purchasing > > With this I intend to run all the stories which are either declared as > "@component sales" or "@component purchasing". > > But it only includes "sales" but not "purchasing". > > You can reproduce it with this code: > > String filter = "+component sales|purchasing"; > > MetaFilter mf = *new* MetaFilter(filter); > > DefaultMetaMatcher dmm = mf.*new* DefaultMetaMatcher(); > > dmm.parse(filter); > > System.*out*.println(dmm.include()); > > Wouldn't it be nice to be able to use regular expressions as meta info > values? Or can I do, what I intended to do, in a different way? > > >
Re: [jbehave-user] Filtering works not as expected with a scenario containing an examples table
I already use StoryControls.doIgnoreMetaFiltersIfGivenStory(true). And I removed the given story in the story. But the result is the same. Maybe tomorrow I can commit the whole project, so that you can reproduce it. On Tue, May 6, 2014 at 11:00 AM, Stephen de Vries wrote: > > On 6 May 2014, at 10:51, Hans Schwäbli > wrote: > > I have the example story, see below. It runs not as expected when > filtering by: +Komponente Bestellung -Skip > > VorgegebeneStories: > shop/stories/Login.story > > > My guess is that the given story doesn’t have the same meta-tags. Fix is > to set: StoryControls.doIgnoreMetaFiltersIfGivenStory(true) > > See: http://jira.codehaus.org/browse/JBEHAVE-789 > >
[jbehave-user] Filtering works not as expected with a scenario containing an examples table
I have the example story, see below. It runs not as expected when filtering
by: +Komponente Bestellung -Skip
The first two scenarios are run, which is okay. But the last one with the
exmaples table is NOT run. The log output is:
Szenario: Rabattgrenzen werden erreicht
Beispiele:
Wenn ein Kunde T-Shirts bestellt
Dann gilt eine Ermässigung von Prozent
Und kostet ein T-Shirt pro Stück Euro
|Anzahl|Rabatt|Preis|
|49|0|10|
|50|10|9|
|99|10|9|
|100|20|8|
[DEBUG] Meta[properties={}] excluded by filter '+Komponente Bestellung
-Skip'
[DEBUG] Meta[properties={}] excluded by filter '+Komponente Bestellung
-Skip'
[DEBUG] Meta[properties={}] excluded by filter '+Komponente Bestellung
-Skip'
[DEBUG] Meta[properties={}] excluded by filter '+Komponente Bestellung
-Skip'
What is my fault? Why is this scenario excluded in JBehave 4.0 beta 7?
Bei Bestellungen muss geprüft werden, ob Rabatte gelten.
Ausserdem werden bei einem hohen Warenwert keine Versandkosten berechnet.
Meta:
@Komponente Bestellung
@Anforderung OOS-1859
@Verfasser Guybrush Threepwood
Erzählung:
Um Angebote und Rechnungen zu erstellen
Als ein Sachbearbeiter im Verkauf
Möchte ich Rabatte, Versandkosten und Lagerbestand berücksichtigen
VorgegebeneStories:
shop/stories/Login.story
Szenario: Kleine Menge wird bestellt
Gegeben im Lager sind 300 T-Shirts
Wenn ein Kunde 5 T-Shirts bestellt
Dann ist die Bestellung auf Lager
Und gilt eine Ermässigung von 0 Prozent
Und kostet ein T-Shirt pro Stück 10 Euro
Und betragen die Versandkosten 7,50 Euro
Und ist der Bestellwert 57,50 Euro
Szenario: Versandkosten fallen weg
Wenn ein Kunde 20 T-Shirts bestellt
Dann betragen die Versandkosten 0 Euro
Und ist der Bestellwert 200 Euro
Szenario: Rabattgrenzen werden erreicht
!--TODO: Gesamtbestellwert könnte auch noch geprüft werden.
Wenn ein Kunde T-Shirts bestellt
Dann gilt eine Ermässigung von Prozent
Und kostet ein T-Shirt pro Stück Euro
Beispiele:
|--|- |-|
|Anzahl|Rabatt|Preis|
|--|--|-|
|49|0 |10 |
|50|10|9|
|99|10|9|
|100 |20|8|
|--|--|-|
[jbehave-user] Using regular expressions as a meta info value is not supported as it seems
I tried to use a regular expression as a meta info value: +component sales|purchasing With this I intend to run all the stories which are either declared as "@component sales" or "@component purchasing". But it only includes "sales" but not "purchasing". You can reproduce it with this code: String filter = "+component sales|purchasing"; MetaFilter mf = *new* MetaFilter(filter); DefaultMetaMatcher dmm = mf.*new* DefaultMetaMatcher(); dmm.parse(filter); System.*out*.println(dmm.include()); Wouldn't it be nice to be able to use regular expressions as meta info values? Or can I do, what I intended to do, in a different way?
[jbehave-user] Unexpected behavior of meta filtering concering given stories
I discovered an unexpected behavior when I used meta filtering and a given story. The meta filter looks like this: +component sales This runs a story (lets call it sales.story) because it containes the meta information "@component sales". The sales.story uses "GivenStories: login.story". That given story does not contain any meta information. My intuitive expectation is that when I run stories using the meta information filter "+component sales" that it does not only run sales.story but also its given story since it is a precondition. But it does not run the given story. I could solve that by adding a meta information to login.story like "@component login" and using this meta filter: +component sales login. But this is not transparent to me. I would have to analyse what GivenStories are used in the stories I want to run in order to define the right meta filtering. That can be very tricky and error-prone. My feeling is that it would be logical that given stories (and its transitive given stories) are always executed if their parent story is matching the meta filtering. Or what do you think?
Re: [jbehave-user] GivenStories does not work in my example (4.x branch)
As it seems it is not yet published in the Maven repository. http://mvnrepository.com/artifact/org.jbehave/jbehave-core But I got it from by using the settings.xml of jbehave-core. It works now. Thank you very much! On Fri, May 2, 2014 at 2:16 PM, Mauro Talevi wrote: > Hi Hans, > > the issue has been noted and fixed. The given stories were only executed > at scenario level but not at story level. > > A new 4.0-beta-7 is being released. > > Cheers > > > On 02/05/2014 11:36, Hans Schwäbli wrote: > >> Somehow GivenStories does not work as expected in the 4.x branch. It is >> not executed. >> But when I use jbehave-core 3.9, then the GivenStories are executed. >> See my example below. It is in German, I changed the story language. >> GivenStories is "VorgegebeneStories". >> Maybe this information is enough to help me. Otherwise I can commit the >> example somewhere. It is not so easy from within a company in the financial >> industry since prevents any cloud access, including Github. >> Story: >> Bei Bestellungen muss geprüft werden, ob Rabatte gelten. >> Ausserdem werden bei einem hohen Warenwert keine Versandkosten berechnet. >> >> Meta: >> @Komponente Bestellung >> @Anforderung Y1776 >> @Verfasser Guybrush Threepwood >> >> Erzählung: >> Um Angebote und Rechnungen zu erstellen >> Als ein Sachbearbeiter im Verkauf >> Möchte ich Rabatte, Versandkosten und Lagerbestand berücksichtigen >> >> VorgegebeneStories: shop/stories/Login.story >> >> Szenario: Kleine Menge wird bestellt >> Gegeben im Lager sind 300 T-Shirts >> >> > > - > To unsubscribe from this list, please visit: > >http://xircles.codehaus.org/manage_email > > >
Re: [jbehave-user] StoryReporter does not contain storyMeta(Meta meta) method
Ah, okay, I see. Then I think I can do what I want with it. I want to use a meta information which represents a link to the test case in HP Quality Center. Meta: @qc-testcase Root/Test/Test-Testset/TesA In StoryReporter.afterStory(...) I want to upload the test result into HP Quality Center at runtime using its REST-API. I wanted to store the meta information in beforeStory(...) so that I can use it later. But as it seems I can use scenarioMeta(...) for that purpose since it is always merged. So it is okay for me, thank you! On Fri, May 2, 2014 at 2:31 PM, Mauro Talevi wrote: > The meta at story level is always merged with the meta at scenario level. > > This is why only the resulting meta is reported. > > We could add the reporting of story level meta, but what is your use-case? > > > On 02/05/2014 14:22, Hans Schwäbli wrote: > >> org.jbehave.core.reporters.StoryReporter contains a scenarioMeta(Meta >> meta) method. >> But it does not contain a method like storyMeta(Meta meta). >> I need to access the Meta information for the story in the StoryReporter. >> Was it forgotton to add that method into StoryReporter or did I overlook >> something (like last time when I searched for "afterStep")? >> > > > - > To unsubscribe from this list, please visit: > >http://xircles.codehaus.org/manage_email > > >
[jbehave-user] StoryReporter does not contain storyMeta(Meta meta) method
org.jbehave.core.reporters.StoryReporter contains a scenarioMeta(Meta meta) method. But it does not contain a method like storyMeta(Meta meta). I need to access the Meta information for the story in the StoryReporter. Was it forgotton to add that method into StoryReporter or did I overlook something (like last time when I searched for "afterStep")?
[jbehave-user] Running on Emptiness
I discovered that I can run a completely empty story. It contains nothing, no narrative, no scenarios and no steps, nothing. If I run it then no failure is shown. Why is so much allowed when writing a story? Why is it not required that a story has at least one step and that there is no scenario containing zero steps?
[jbehave-user] GivenStories does not work in my example (4.x branch)
Somehow GivenStories does not work as expected in the 4.x branch. It is not executed. But when I use jbehave-core 3.9, then the GivenStories are executed. See my example below. It is in German, I changed the story language. GivenStories is "VorgegebeneStories". Maybe this information is enough to help me. Otherwise I can commit the example somewhere. It is not so easy from within a company in the financial industry since prevents any cloud access, including Github. Story: Bei Bestellungen muss geprüft werden, ob Rabatte gelten. Ausserdem werden bei einem hohen Warenwert keine Versandkosten berechnet. Meta: @Komponente Bestellung @Anforderung Y1776 @Verfasser Guybrush Threepwood Erzählung: Um Angebote und Rechnungen zu erstellen Als ein Sachbearbeiter im Verkauf Möchte ich Rabatte, Versandkosten und Lagerbestand berücksichtigen VorgegebeneStories: shop/stories/Login.story Szenario: Kleine Menge wird bestellt Gegeben im Lager sind 300 T-Shirts
[jbehave-user] Meaning of Step Results?
These step results exist: failed, ignorable, notPerformed, pending, skipped, successful, silent. I know what these mean: failed, notPerformed, pending and successful. But what is the meaning of the other step results? ignorable? skipped? silent? When do they occur?
Re: [jbehave-user] How to get working JBehave sources in Eclipse?
I cannot find that feature in m2e 1.5. When importing the projects I still can select the same options how to deal with unresolved dependencies: resolve later or do not execute. Don't be upset, but I will stick to the solution I found in order not to lose more time on this, at least for a while. Mauro, thank you for comitting that file into the repository. I updated it afterwards in this mailing list since I forgot one dependency. On Tue, Apr 29, 2014 at 4:56 PM, Hans Schwäbli wrote: > Hello Gavião, > > maybe I didn't spend enough time to discover why it did not work after I > found a solution. It had a lot of compile errors if I don't pre-build it > outside Eclipse before importing it. > > I don't know if copying the settings.xml to the .m2 folder would fix the > problem. I can put settings.xml anywhere with Eclipse as long as I tell > Eclipse where that file is. > > I will try that experimental feature next time. I now upgraded m2e from > 1.4 to 1.5. > > > On Tue, Apr 29, 2014 at 4:21 PM, Cristiano Gavião wrote: > >> >> On 29-04-2014 10:29, Hans Schwäbli wrote: >> >> It is a bit more tricky than I thought to get that sources working in >> Eclipse. >> >> First I have to check jbehave-core out. But then I don't must import it >> into Eclipse. First I have to configure the settings.xml with the company >> proxy settings I need and build everything with: mvn -s settings.xml clean >> install -Dmaven.test.skip=true >> >> >> why don't you just copy the profiles/repositories specified in the >> provided settings.xml to your ~user/.m2/settings.xml? >> >> >> If I don't do this but import the projects into Eclipse, then JBehave >> dependencies are downloaded from the maven repository instead of using the >> checked out ones. >> >> Jbehave snapshots jars are not being deployed into any remote repository >> (at least not that I know) so I think this is not true. m2e will get those >> dependencies from your local repository only if they aren't imported in the >> eclipse workspace... >> >> >> >> Then I need to configure Eclipse so that it uses the Maven >> lifecycleMappingMetadata. Below I updated it for the >> maven-dependency-plugin exclusion (see below). >> >> version 1.5 of m2e ( >> http://download.eclipse.org/technology/m2e/milestones/1.5 ) has the >> feature that Mauro have said... it is just a matter of choose the option >> and you don't need to deal with POM changes... >> >> >> In Eclipse I must use the settings.xml file from JBehave. >> >> Now I finally can import the projects into Eclipse (as Maven projects). >> >> After it builds I have just one compile error: JRubySteps cannot be >> resolved to a type. I can ignore that (delete the JRuby example project). >> >> There are quite some pitfalls, at least for my brain. >> >> >> >> >> >> >> >> org.apache.maven.plugins >> maven-dependency-plugin >> [1.0.0,) >> >> copy-dependencies >> unpack >> >> >> >> >> >> >> >> >> org.jbehave >> >> jbehave-maven-plugin >> >> >> [3.10-SNAPSHOT,) >> >> >> >> unpack-view-resources >> >> >> >> >> >> >> >> >> >> >> org.jvnet.hudson.tools >> >> >> maven-hpi-plugin >> >> >> [3.0.1,) >> >> >> insert-test >> test-hpl >> >> resolve-test-dependencies >> >> >> >> >> >> >> >> >> >> org.scala-tools >> >> maven-sc
Re: [jbehave-user] How to get working JBehave sources in Eclipse?
Hello Gavião, maybe I didn't spend enough time to discover why it did not work after I found a solution. It had a lot of compile errors if I don't pre-build it outside Eclipse before importing it. I don't know if copying the settings.xml to the .m2 folder would fix the problem. I can put settings.xml anywhere with Eclipse as long as I tell Eclipse where that file is. I will try that experimental feature next time. I now upgraded m2e from 1.4 to 1.5. On Tue, Apr 29, 2014 at 4:21 PM, Cristiano Gavião wrote: > > On 29-04-2014 10:29, Hans Schwäbli wrote: > > It is a bit more tricky than I thought to get that sources working in > Eclipse. > > First I have to check jbehave-core out. But then I don't must import it > into Eclipse. First I have to configure the settings.xml with the company > proxy settings I need and build everything with: mvn -s settings.xml clean > install -Dmaven.test.skip=true > > > why don't you just copy the profiles/repositories specified in the > provided settings.xml to your ~user/.m2/settings.xml? > > > If I don't do this but import the projects into Eclipse, then JBehave > dependencies are downloaded from the maven repository instead of using the > checked out ones. > > Jbehave snapshots jars are not being deployed into any remote repository > (at least not that I know) so I think this is not true. m2e will get those > dependencies from your local repository only if they aren't imported in the > eclipse workspace... > > > > Then I need to configure Eclipse so that it uses the Maven > lifecycleMappingMetadata. Below I updated it for the > maven-dependency-plugin exclusion (see below). > > version 1.5 of m2e ( > http://download.eclipse.org/technology/m2e/milestones/1.5 ) has the > feature that Mauro have said... it is just a matter of choose the option > and you don't need to deal with POM changes... > > > In Eclipse I must use the settings.xml file from JBehave. > > Now I finally can import the projects into Eclipse (as Maven projects). > > After it builds I have just one compile error: JRubySteps cannot be > resolved to a type. I can ignore that (delete the JRuby example project). > > There are quite some pitfalls, at least for my brain. > > > > > > > > org.apache.maven.plugins > maven-dependency-plugin > [1.0.0,) > > copy-dependencies > unpack > > > > > > > > > org.jbehave > > jbehave-maven-plugin > > > [3.10-SNAPSHOT,) > > > > unpack-view-resources > > > > > > > > > > > org.jvnet.hudson.tools > > > maven-hpi-plugin > > > [3.0.1,) > > > insert-test > test-hpl > > resolve-test-dependencies > > > > > > > > > > org.scala-tools > > maven-scala-plugin > > > [2.9.1,) > > > add-source > compile > testCompile > > > > > > > > > de.saumya.mojo > > jruby-maven-plugin > > > [0.29.1,) > > > compile > > > > > > > > > > > On Tue, Apr 29, 2014 at 12:59 PM, Hans Schwäbli < > bugs.need.love@gmail.com> wrote: > >> Maybe Eclipse 4.4 has this feature, I
Re: [jbehave-user] How to get working JBehave sources in Eclipse?
It is a bit more tricky than I thought to get that sources working in Eclipse. First I have to check jbehave-core out. But then I don't must import it into Eclipse. First I have to configure the settings.xml with the company proxy settings I need and build everything with: mvn -s settings.xml clean install -Dmaven.test.skip=true If I don't do this but import the projects into Eclipse, then JBehave dependencies are downloaded from the maven repository instead of using the checked out ones. Then I need to configure Eclipse so that it uses the Maven lifecycleMappingMetadata. Below I updated it for the maven-dependency-plugin exclusion (see below). In Eclipse I must use the settings.xml file from JBehave. Now I finally can import the projects into Eclipse (as Maven projects). After it builds I have just one compile error: JRubySteps cannot be resolved to a type. I can ignore that (delete the JRuby example project). There are quite some pitfalls, at least for my brain. org.apache.maven.plugins maven-dependency-plugin [1.0.0,) copy-dependencies unpack org.jbehave jbehave-maven-plugin [3.10-SNAPSHOT,) unpack-view-resources org.jvnet.hudson.tools maven-hpi-plugin [3.0.1,) insert-test test-hpl resolve-test-dependencies org.scala-tools maven-scala-plugin [2.9.1,) add-source compile testCompile de.saumya.mojo jruby-maven-plugin [0.29.1,) compile On Tue, Apr 29, 2014 at 12:59 PM, Hans Schwäbli < bugs.need.love@gmail.com> wrote: > Maybe Eclipse 4.4 has this feature, I haven't discovered it in 4.3. > > I created a lifecycle mappings metadata which solves this problem (such > things could be added to a Wiki for instance): > > > > > > > > org.jbehave > > jbehave-maven-plugin > > > [4.0-SNAPSHOT,) > > > > unpack-view-resources > > > > > > > > > > > org.jvnet.hudson.tools > > > maven-hpi-plugin > > > [3.0.1,) > > > insert-test > test-hpl > > resolve-test-dependencies > > > > > > > > > > org.scala-tools > > maven-scala-plugin > > > [2.9.1,) > > > add-source > compile > testCompile > > > > > > > > > de.saumya.mojo > > jruby-maven-plugin > > > [0.29.1,) >
Re: [jbehave-user] How to get working JBehave sources in Eclipse?
Maybe Eclipse 4.4 has this feature, I haven't discovered it in 4.3. I created a lifecycle mappings metadata which solves this problem (such things could be added to a Wiki for instance): org.jbehave jbehave-maven-plugin [4.0-SNAPSHOT,) unpack-view-resources org.jvnet.hudson.tools maven-hpi-plugin [3.0.1,) insert-test test-hpl resolve-test-dependencies org.scala-tools maven-scala-plugin [2.9.1,) add-source compile testCompile de.saumya.mojo jruby-maven-plugin [0.29.1,) compile On Mon, Apr 28, 2014 at 11:02 PM, Mauro Talevi wrote: > Yes, the m2e plugin is very annoying in this. IMO it's one of the > worst design decisions they've made when migrating from the original > m2eclipse plugin. But with recent versions, Eclipse allows you to mark as > ignored these errors without modifying the pom.xml. The feature is marked > as experimental but it's stable and works fine. It stores the info to be > ignored in the workspace (I'm not sure if it can exported and re-imported > easily though). > > This is why the source code is not polluted with the pom.xml modifications > - as you say to preserve IDE neutrality. > > On 28/04/2014 14:46, Hans Schwäbli wrote: > > Thank you. > > I forgot about the page which explains the JBehave source building. So I > didn't see that I need to use that settings.xml file. > > But I think my biggest mistake was when importing the maven project into > Eclipse. The import wizard shows me the plugins which can't be found. There > I can choose in a little dropdown that m2e writes into the pom.xml that > these plugins are ignored. > > It works now with that approach. > > However, you could add these settings into the pom.xml parent file, so it > would be no problem to import the maven projects into Eclipse. But I am > afraid that you want to be IDE neutral. In that case a documentation on how > to import JBehave sources into Eclipse would be nice. I would be willing to > contribute if you provide some Wiki for JBehave (because I cannot commit > anything in Github from the company and it is too much overhead to create > HTML pages for me). > > > On Fri, Apr 25, 2014 at 4:49 PM, Cristiano Gavião wrote: > >> first things you must learn before are: >> >> - how works a maven settings.xml and how to set it in your machine; >> >> - how m2e works related to a pure maven outside eclipse... >> >> - how to make m2e ignore unsupported plugins... >> >> here you have tips how to build outside eclipse: >> http://jbehave.org/reference/latest/building-source.html >> >> for the rest, I'm sure you will find lot of materials on the net... >> >> Cristiano >> >> >> On 25-04-2014 10:34, Hans Schwäbli wrote: >> >>> I try to import the projects of jbehave-core (branch 4.x) into Eclipse >>> Kepler as Maven projects. >>> It causes a lot of problems: 127 errors (compile and pom problems). >>> For example the error in jbehave-core\examples\core\pom.xml is: >>> >>> "Multiple annotations found at this line: >>> >>> - maven-dependency-plugin (goals "copy-dependencies", "unpack") is not >>> supported by m2e. >>> >>> - Plugin execution not covered by lifecycle configuration: >>> org.jbehave:jbehave-maven-plugin:4.0-SNAPSHOT:unpack-view-resources >>> (execution: unpack-view-resources, phase: process- >>> >>> resources)" >>
Re: [jbehave-user] What about a Wiki?
I cannot create any page in the JBehave space. I cannot select JBehave space only lzPack and SCM. Maybe JBehave space is closed. Could you please enable me? My user name is: otto_diesel On Tue, Apr 29, 2014 at 10:23 AM, Hans Schwäbli < bugs.need.love@gmail.com> wrote: > Great! I did not know that it exists. It is very empty currently. > > I could add a page describing step by step how to import the sources into > Eclipse. And I could add the best practices I propose for JBehave and which > I sent to this mailing list some months ago. And there are a lot of other > use cases and for other users and developers. > > Maybe a link in the navigation bar can be added to the JBehave homepage > pointing to this Wiki? > > > On Mon, Apr 28, 2014 at 11:07 PM, Mauro Talevi > wrote: > >> Yes a Codehaus Confluence wiki space exists for JBehave and can be used >> for user contributions. >> >> We'd need to check on permissions and all that for contributors. >> >> >> On 28/04/2014 17:00, Mirko Friedenhagen wrote: >> >>> Hello, >>> >>> what about http://docs.codehaus.org/display/JBEHAVE/? I do not know >>> about the permissions but could imagine a Wiki-space named JBEHAVEUSER >>> for user contributions next to the "official" one would be a good >>> place with easy interwiki links :-). >>> Regards Mirko >>> -- >>> http://illegalstateexception.blogspot.com/ >>> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) >>> https://bitbucket.org/mfriedenhagen/ >>> >>> >>> On Mon, Apr 28, 2014 at 4:17 PM, Hans Schwäbli >>> wrote: >>> >>>> There are no wiki pages for JBehave as it seems. >>>> >>>> What about looking for a free wiki hoster and registrating a offical >>>> wiki >>>> place for JBehave? >>>> >>>> This would be a place where the community can provide documentation on >>>> JBehave with very little overhead. After all wiki means "fast". >>>> >>>> If you agree I can look for suitable hosting sites. >>>> >>> - >>> 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] jbehave-core sources include examples
Currently I am just interested in the sources for the JBehave examples. I cannot check them out separetely since they are contained in jbehave-core, which are a lot of maven projects, sources and hundreds of dependencies. jbehave-core is a very large repository even without the examples. Checking examples out into a IDE and building them is more complicated and takes more time than it could be because of this. What do you think about separating the examples from jbehave-core?
Re: [jbehave-user] What about a Wiki?
Great! I did not know that it exists. It is very empty currently. I could add a page describing step by step how to import the sources into Eclipse. And I could add the best practices I propose for JBehave and which I sent to this mailing list some months ago. And there are a lot of other use cases and for other users and developers. Maybe a link in the navigation bar can be added to the JBehave homepage pointing to this Wiki? On Mon, Apr 28, 2014 at 11:07 PM, Mauro Talevi wrote: > Yes a Codehaus Confluence wiki space exists for JBehave and can be used > for user contributions. > > We'd need to check on permissions and all that for contributors. > > > On 28/04/2014 17:00, Mirko Friedenhagen wrote: > >> Hello, >> >> what about http://docs.codehaus.org/display/JBEHAVE/? I do not know >> about the permissions but could imagine a Wiki-space named JBEHAVEUSER >> for user contributions next to the "official" one would be a good >> place with easy interwiki links :-). >> Regards Mirko >> -- >> http://illegalstateexception.blogspot.com/ >> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) >> https://bitbucket.org/mfriedenhagen/ >> >> >> On Mon, Apr 28, 2014 at 4:17 PM, Hans Schwäbli >> wrote: >> >>> There are no wiki pages for JBehave as it seems. >>> >>> What about looking for a free wiki hoster and registrating a offical wiki >>> place for JBehave? >>> >>> This would be a place where the community can provide documentation on >>> JBehave with very little overhead. After all wiki means "fast". >>> >>> If you agree I can look for suitable hosting sites. >>> >> - >> 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] Lifecycle naming
Yes, it is subjective. "Background" is not perfect, I agree. Another topic: Lifecycle refers to scenarios. But I think there are cases where a JBehave user needs the same for stories. I compare it to JUnit where there is @Before and @After which is executed for every test in a class. A JUnit class is comparable to a story in a way. What is missing then is something like @BeforeClass and @AfterClass. In a story it could be done with GivenStories to support something like @BeforeClass from JUnit. But it seems there is no thing for @AfterClass in a story. Cleanups could be done for all scenarios of a story in such a part. A solution might be to put it into the last scenario of a story maybe. On Mon, Apr 28, 2014 at 10:56 PM, Mauro Talevi wrote: > It's rather debatable whether one sounds more natural or technical than > the other. Also, background tends to suggest concurrency - which is not > the case. > > In any case, it's all subjective. If you prefer, you can configure your > own "custom" company locale (akin to a new language) with the name you > choose.The Eclipse plugin will pick up the locale you've configured in > your Configuration. > > Or you can use the Gherkin syntax directly. > > > On 28/04/2014 12:31, Hans Schwäbli wrote: > >> I have a little suggestion concerning "lifecycle" steps. >> This is a cool feature. But the name "lifecycle" sounds quite technical >> and can intimidate testers and business analysts, unlike the other elements >> of a story. >> In Cucumber they call it "background" which does not sound so technical. >> It is not a big issue for me, but I think a "natural" name like >> "background" would be more appropriate. Of course I could change the >> keyword names locally (for the Eclipse plugin it would be more tricky), but >> just as a feedback. >> > > > - > To unsubscribe from this list, please visit: > >http://xircles.codehaus.org/manage_email > > >
[jbehave-user] What about a Wiki?
There are no wiki pages for JBehave as it seems. What about looking for a free wiki hoster and registrating a offical wiki place for JBehave? This would be a place where the community can provide documentation on JBehave with very little overhead. After all wiki means "fast". If you agree I can look for suitable hosting sites.
Re: [jbehave-user] How to get working JBehave sources in Eclipse?
Thank you. I forgot about the page which explains the JBehave source building. So I didn't see that I need to use that settings.xml file. But I think my biggest mistake was when importing the maven project into Eclipse. The import wizard shows me the plugins which can't be found. There I can choose in a little dropdown that m2e writes into the pom.xml that these plugins are ignored. It works now with that approach. However, you could add these settings into the pom.xml parent file, so it would be no problem to import the maven projects into Eclipse. But I am afraid that you want to be IDE neutral. In that case a documentation on how to import JBehave sources into Eclipse would be nice. I would be willing to contribute if you provide some Wiki for JBehave (because I cannot commit anything in Github from the company and it is too much overhead to create HTML pages for me). On Fri, Apr 25, 2014 at 4:49 PM, Cristiano Gavião wrote: > first things you must learn before are: > > - how works a maven settings.xml and how to set it in your machine; > > - how m2e works related to a pure maven outside eclipse... > > - how to make m2e ignore unsupported plugins... > > here you have tips how to build outside eclipse: > http://jbehave.org/reference/latest/building-source.html > > for the rest, I'm sure you will find lot of materials on the net... > > Cristiano > > > On 25-04-2014 10:34, Hans Schwäbli wrote: > >> I try to import the projects of jbehave-core (branch 4.x) into Eclipse >> Kepler as Maven projects. >> It causes a lot of problems: 127 errors (compile and pom problems). >> For example the error in jbehave-core\examples\core\pom.xml is: >> >> "Multiple annotations found at this line: >> >> - maven-dependency-plugin (goals "copy-dependencies", "unpack") is not >> supported by m2e. >> >> - Plugin execution not covered by lifecycle configuration: >> org.jbehave:jbehave-maven-plugin:4.0-SNAPSHOT:unpack-view-resources >> (execution: unpack-view-resources, phase: process- >> >> resources)" >> And for many other poms: >> "Could not find artifact org.jbehave:jbehave-maven- >> plugin:pom:4.0-SNAPSHOT" >> And: >> "Project build error: Unknown packaging: hpi" >> And if I build jbehave-core with maven (clean install without tests), >> then It fails with this error quite early at JBehave Hudson Plugin: >> >> [ERROR] Failed to execute goal >> org.kohsuke:access-modifier-checker:1.4:enforce >> (default-enforce) on project jbehave-hudson-plugin: Execution >> default-enforce of goal org.kohsuke:access-modifier-checker:1.4:enforce >> failed: Plugin org.kohsuke:access-modifier-checker:1.4 or one of its >> dependencies could not be resolved: Could not find artifact >> org.jenkins-ci:annotation-indexer:jar:1.4 in Central ( >> http://repo1.maven.org/maven2) -> [Help 1] >> What is the problem? Or how do you get working projects of it in Eclipse >> after cloning it from Github? >> > > > - > To unsubscribe from this list, please visit: > >http://xircles.codehaus.org/manage_email > > >
[jbehave-user] Lifecycle naming
I have a little suggestion concerning "lifecycle" steps. This is a cool feature. But the name "lifecycle" sounds quite technical and can intimidate testers and business analysts, unlike the other elements of a story. In Cucumber they call it "background" which does not sound so technical. It is not a big issue for me, but I think a "natural" name like "background" would be more appropriate. Of course I could change the keyword names locally (for the Eclipse plugin it would be more tricky), but just as a feedback.
Re: [jbehave-user] Some issues with lifecyle steps
Ok, I will raise an Jira issue because of the execution depending on
outcome.
Concerning pending steps: It looks the same in the report when no step is
found and when a matching step method has been marked @Pending. But this is
not the same situation to me but the same word is used.
Wouldn't it be more intuitive and helpful if one can see whether the step
implementation exists but is not yet implemented (case A) or if it was not
found (case B)?
On Fri, Apr 25, 2014 at 6:44 PM, Mauro Talevi wrote:
> A step that is not found (or whose signature is not matched which is the
> same) is considered pending. You can think pending as synonymous to not
> found.
>
> Passing nulls around is not a safe nor good practice as it simply shifts
> the problem without solving it. You can activate the step monitor to
> investigate missing steps. We can make the debugging easier perhaps.
>
> Please send a scenario to reproduce the issue with given stories on 4.0
>
> There is a case for lifecycle after steps to be executed depending on
> outcome, like the @AfterScenario steps. Please raise a JIRA issue.
>
> Cheers
>
> On 25 Apr 2014, at 13:23, Hans Schwäbli
> wrote:
>
> I tried the new lifecylce steps in JBehave 4 beta-6.
>
> I wondered why my lifecycle after step was not executed (pending state).
>
> It was because the step method used a argument although the step name does
> not contain a parameter:
>
> @Given("the user logs out")
>
> *public* *void* logout(String *user*) {}
>
> This mistake is a bit tricky to solve. What do you think about indicating
> that no step was found instead of using state "pending"? Or you could use
> that step, pass null into the step and log a warning?
>
> But this might apply to all steps, not just lifecycle steps.
>
> With lifecycle steps I have another issue. If a step has failed then the
> after lifecycle steps are not exectuted.
>
> I think it would be good to also have after steps which are executed even
> if a normal step has failed. Then I could do some cleanups in the after
> steps. But if the after steps are not called because a normal step failed,
> then I cannot do such cleanups. What do you think about this?
>
> By the way, I only used lifecycle because I have problems with
> GivenStories. It is not executed but ignored. It used to work in former
> versions. I couldn't yet figure out what the problem is, but I will provide
> a reproducible example.
>
>
[jbehave-user] How to get working JBehave sources in Eclipse?
I try to import the projects of jbehave-core (branch 4.x) into Eclipse Kepler as Maven projects. It causes a lot of problems: 127 errors (compile and pom problems). For example the error in jbehave-core\examples\core\pom.xml is: "Multiple annotations found at this line: - maven-dependency-plugin (goals "copy-dependencies", "unpack") is not supported by m2e. - Plugin execution not covered by lifecycle configuration: org.jbehave:jbehave-maven-plugin:4.0-SNAPSHOT:unpack-view-resources (execution: unpack-view-resources, phase: process- resources)" And for many other poms: "Could not find artifact org.jbehave:jbehave-maven-plugin:pom:4.0-SNAPSHOT" And: "Project build error: Unknown packaging: hpi" And if I build jbehave-core with maven (clean install without tests), then It fails with this error quite early at JBehave Hudson Plugin: [ERROR] Failed to execute goal org.kohsuke:access-modifier-checker:1.4:enforce (default-enforce) on project jbehave-hudson-plugin: Execution default-enforce of goal org.kohsuke:access-modifier-checker:1.4:enforce failed: Plugin org.kohsuke:access-modifier-checker:1.4 or one of its dependencies could not be resolved: Could not find artifact org.jenkins-ci:annotation-indexer:jar:1.4 in Central ( http://repo1.maven.org/maven2) -> [Help 1] What is the problem? Or how do you get working projects of it in Eclipse after cloning it from Github?
[jbehave-user] Some issues with lifecyle steps
I tried the new lifecylce steps in JBehave 4 beta-6.
I wondered why my lifecycle after step was not executed (pending state).
It was because the step method used a argument although the step name does
not contain a parameter:
@Given("the user logs out")
*public* *void* logout(String *user*) {}
This mistake is a bit tricky to solve. What do you think about indicating
that no step was found instead of using state "pending"? Or you could use
that step, pass null into the step and log a warning?
But this might apply to all steps, not just lifecycle steps.
With lifecycle steps I have another issue. If a step has failed then the
after lifecycle steps are not exectuted.
I think it would be good to also have after steps which are executed even
if a normal step has failed. Then I could do some cleanups in the after
steps. But if the after steps are not called because a normal step failed,
then I cannot do such cleanups. What do you think about this?
By the way, I only used lifecycle because I have problems with
GivenStories. It is not executed but ignored. It used to work in former
versions. I couldn't yet figure out what the problem is, but I will provide
a reproducible example.
Re: [jbehave-user] Exporting test results into HP Quality Center (or any other test management tool)
Sorry, you are right. I now closed the Jira issue which I had created for
this.
Yes, I will take a look at the timings as soon as I migrate to the 4.x
branch. Currentyl I am still waiting for the first non-beta version on this
branch.
On Fri, Apr 18, 2014 at 9:34 AM, Mauro Talevi wrote:
> Hi Hans,
>
> the afterStep() is not missing because of an oversight. It is in fact
> split into several methods, one for each step outcome.
>
> void successful(String step);
>
> void ignorable(String step);
>
> void pending(String step);
>
> void notPerformed(String step);
>
> void failed(String step, Throwable cause);
>
> The timings of the step have already been implemented in the 4.x branch,
> by-passing the StoryReporter altogether. You might want to have a look at
> it.
>
> Cheers
>
>
> On 17/04/2014 14:38, Hans Schwäbli wrote:
>
> Now I solved this by creating a class impleting
> org.jbehave.core.reporters.StoryReporter.
>
> It has enough methods which intercept the JBehave execution workflow and
> pass the information which I need, like scenario name.
>
> In a way this seems to be the right way to do it anyway since I am
> reporting the JBehave result into a test management tool.
>
> But I would be happy if you could add a method afterStep(...) into the
> StoryReporter interface. Because this would allow me to measure the
> duration of the step execution. I have workarounds for this, but they are
> more complicated to implement. I created a Jira task for this.
>
>
> On Fri, Apr 11, 2014 at 12:48 PM, Hans Schwäbli <
> bugs.need.love@gmail.com> wrote:
>
>> Hello Mauro,
>>
>> that sounds good to use the uponOutcome, thank you! I overlooked that.
>>
>> Parsing the XML in a good way would require a XSD file I believe, but it
>> does not exist, so I try not to use that approach.
>>
>> Now it looks like this:
>>
>> @AfterScenario(uponType=ScenarioType.NORMAL,
>> uponOutcome=AfterScenario.Outcome.SUCCESS)
>> public void afterScenarioSuccess(@Named("qc-testcase") String
>> qcTestcase) {
>> // TODO Export result into HP QC.
>> }
>>
>> With that I can export the result in a basic way into HP QC.
>>
>> But I should also export the JBehave XML result file into HP QC. For this
>> purpose I need to know which story is running. How can I get to that
>> information in the method above?
>>
>> Furthermore it would be more suitable to have XML results per scenario
>> since a test in HP QC (and perhaps also in many other test managment tools)
>> is best represented by a JBehave scenario. Is it possible to configure
>> JBehave so that it produces XML result files per scenario?
>>
>>
>> On Thu, Apr 10, 2014 at 11:21 PM, Mauro Talevi <
>> mauro.tal...@aquilonia.org> wrote:
>>
>>> @AfterScenario supports the variable uponOutcome to determine if the
>>> scenario has failed or not.
>>>
>>> Else you can parse the XML of the story and extract the scenario info.
>>>
>>>
>>> On 10/04/2014 13:42, Hans Schwäbli wrote:
>>>
>>>> I achieved to create Java classes which can export test results into HP
>>>> Quality Center by using its REST interface.
>>>> But now I wonder how to extract the outcome from the JBehave run so
>>>> that I can export the results. I want to export that in a very basic way:
>>>> test result with an attached XML report.
>>>> I identify the tests in Quality Center by using a Meta info per
>>>> scenario: @qc-testcase Root/Test Folder x/Test Set y/My Test
>>>> This Meta info I can extract in a method like this:
>>>> @AfterScenario
>>>> public void afterScenario(@Named("qc-testcase") String qcTestcase) {}
>>>> Each scenario shall match a test in Quality Center.
>>>> My first idea was to export the outcome while the JBehave tests run.
>>>> That would require to get to the information in a method annotated with
>>>> @AfterScenario. But how can I determine in this method what outcome of the
>>>> scenario is so that I can export that on-the-fly into HP QC?
>>>> Another idea was to parse the genereated XML file after the run has
>>>> finished. But it has no schema file. So I cannot generate Java classes for
>>>> it by using JAXB in order to parse the result in a good way. Furthermore
>>>> there is no total outcome result printed in the XML, only for the step
>>>> outcome. Besides that I should have an XML file per scenario, so that I can
>>>> attach it to the test result when I export it into HP QC, and I don't know
>>>> if I can achieve that, so that JBehave procduces XML files per scenario.
>>>> How would you solve that?
>>>>
>>>
>>>
>>> -
>>> To unsubscribe from this list, please visit:
>>>
>>>http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>
>
Re: [jbehave-user] Exporting test results into HP Quality Center (or any other test management tool)
Now I solved this by creating a class impleting
org.jbehave.core.reporters.StoryReporter.
It has enough methods which intercept the JBehave execution workflow and
pass the information which I need, like scenario name.
In a way this seems to be the right way to do it anyway since I am
reporting the JBehave result into a test management tool.
But I would be happy if you could add a method afterStep(...) into the
StoryReporter interface. Because this would allow me to measure the
duration of the step execution. I have workarounds for this, but they are
more complicated to implement. I created a Jira task for this.
On Fri, Apr 11, 2014 at 12:48 PM, Hans Schwäbli <
bugs.need.love@gmail.com> wrote:
> Hello Mauro,
>
> that sounds good to use the uponOutcome, thank you! I overlooked that.
>
> Parsing the XML in a good way would require a XSD file I believe, but it
> does not exist, so I try not to use that approach.
>
> Now it looks like this:
>
> @AfterScenario(uponType=ScenarioType.NORMAL,
> uponOutcome=AfterScenario.Outcome.SUCCESS)
> public void afterScenarioSuccess(@Named("qc-testcase") String
> qcTestcase) {
> // TODO Export result into HP QC.
> }
>
> With that I can export the result in a basic way into HP QC.
>
> But I should also export the JBehave XML result file into HP QC. For this
> purpose I need to know which story is running. How can I get to that
> information in the method above?
>
> Furthermore it would be more suitable to have XML results per scenario
> since a test in HP QC (and perhaps also in many other test managment tools)
> is best represented by a JBehave scenario. Is it possible to configure
> JBehave so that it produces XML result files per scenario?
>
>
> On Thu, Apr 10, 2014 at 11:21 PM, Mauro Talevi > wrote:
>
>> @AfterScenario supports the variable uponOutcome to determine if the
>> scenario has failed or not.
>>
>> Else you can parse the XML of the story and extract the scenario info.
>>
>>
>> On 10/04/2014 13:42, Hans Schwäbli wrote:
>>
>>> I achieved to create Java classes which can export test results into HP
>>> Quality Center by using its REST interface.
>>> But now I wonder how to extract the outcome from the JBehave run so that
>>> I can export the results. I want to export that in a very basic way: test
>>> result with an attached XML report.
>>> I identify the tests in Quality Center by using a Meta info per
>>> scenario: @qc-testcase Root/Test Folder x/Test Set y/My Test
>>> This Meta info I can extract in a method like this:
>>> @AfterScenario
>>> public void afterScenario(@Named("qc-testcase") String qcTestcase) {}
>>> Each scenario shall match a test in Quality Center.
>>> My first idea was to export the outcome while the JBehave tests run.
>>> That would require to get to the information in a method annotated with
>>> @AfterScenario. But how can I determine in this method what outcome of the
>>> scenario is so that I can export that on-the-fly into HP QC?
>>> Another idea was to parse the genereated XML file after the run has
>>> finished. But it has no schema file. So I cannot generate Java classes for
>>> it by using JAXB in order to parse the result in a good way. Furthermore
>>> there is no total outcome result printed in the XML, only for the step
>>> outcome. Besides that I should have an XML file per scenario, so that I can
>>> attach it to the test result when I export it into HP QC, and I don't know
>>> if I can achieve that, so that JBehave procduces XML files per scenario.
>>> How would you solve that?
>>>
>>
>>
>> -
>> To unsubscribe from this list, please visit:
>>
>>http://xircles.codehaus.org/manage_email
>>
>>
>>
>
Re: [jbehave-user] Exporting test results into HP Quality Center (or any other test management tool)
Hello Mauro,
that sounds good to use the uponOutcome, thank you! I overlooked that.
Parsing the XML in a good way would require a XSD file I believe, but it
does not exist, so I try not to use that approach.
Now it looks like this:
@AfterScenario(uponType=ScenarioType.NORMAL,
uponOutcome=AfterScenario.Outcome.SUCCESS)
public void afterScenarioSuccess(@Named("qc-testcase") String
qcTestcase) {
// TODO Export result into HP QC.
}
With that I can export the result in a basic way into HP QC.
But I should also export the JBehave XML result file into HP QC. For this
purpose I need to know which story is running. How can I get to that
information in the method above?
Furthermore it would be more suitable to have XML results per scenario
since a test in HP QC (and perhaps also in many other test managment tools)
is best represented by a JBehave scenario. Is it possible to configure
JBehave so that it produces XML result files per scenario?
On Thu, Apr 10, 2014 at 11:21 PM, Mauro Talevi
wrote:
> @AfterScenario supports the variable uponOutcome to determine if the
> scenario has failed or not.
>
> Else you can parse the XML of the story and extract the scenario info.
>
>
> On 10/04/2014 13:42, Hans Schwäbli wrote:
>
>> I achieved to create Java classes which can export test results into HP
>> Quality Center by using its REST interface.
>> But now I wonder how to extract the outcome from the JBehave run so that
>> I can export the results. I want to export that in a very basic way: test
>> result with an attached XML report.
>> I identify the tests in Quality Center by using a Meta info per scenario:
>> @qc-testcase Root/Test Folder x/Test Set y/My Test
>> This Meta info I can extract in a method like this:
>> @AfterScenario
>> public void afterScenario(@Named("qc-testcase") String qcTestcase) {}
>> Each scenario shall match a test in Quality Center.
>> My first idea was to export the outcome while the JBehave tests run. That
>> would require to get to the information in a method annotated with
>> @AfterScenario. But how can I determine in this method what outcome of the
>> scenario is so that I can export that on-the-fly into HP QC?
>> Another idea was to parse the genereated XML file after the run has
>> finished. But it has no schema file. So I cannot generate Java classes for
>> it by using JAXB in order to parse the result in a good way. Furthermore
>> there is no total outcome result printed in the XML, only for the step
>> outcome. Besides that I should have an XML file per scenario, so that I can
>> attach it to the test result when I export it into HP QC, and I don't know
>> if I can achieve that, so that JBehave procduces XML files per scenario.
>> How would you solve that?
>>
>
>
> -
> To unsubscribe from this list, please visit:
>
>http://xircles.codehaus.org/manage_email
>
>
>
[jbehave-user] Exporting test results into HP Quality Center (or any other test management tool)
I achieved to create Java classes which can export test results into HP
Quality Center by using its REST interface.
But now I wonder how to extract the outcome from the JBehave run so that I
can export the results. I want to export that in a very basic way: test
result with an attached XML report.
I identify the tests in Quality Center by using a Meta info per scenario:
@qc-testcase Root/Test Folder x/Test Set y/My Test
This Meta info I can extract in a method like this:
@AfterScenario
public void afterScenario(@Named("qc-testcase") String qcTestcase) {}
Each scenario shall match a test in Quality Center.
My first idea was to export the outcome while the JBehave tests run. That
would require to get to the information in a method annotated with
@AfterScenario. But how can I determine in this method what outcome of the
scenario is so that I can export that on-the-fly into HP QC?
Another idea was to parse the genereated XML file after the run has
finished. But it has no schema file. So I cannot generate Java classes for
it by using JAXB in order to parse the result in a good way. Furthermore
there is no total outcome result printed in the XML, only for the step
outcome. Besides that I should have an XML file per scenario, so that I can
attach it to the test result when I export it into HP QC, and I don't know
if I can achieve that, so that JBehave procduces XML files per scenario.
How would you solve that?
Re: [jbehave-user] Re: Behavior of org.jbehave.core.ConfigurableEmbedder.configuredEmbedder()
I did: http://jira.codehaus.org/i#browse/JBEHAVE-1009 On Mon, Mar 31, 2014 at 11:49 PM, Mauro Talevi wrote: > Could you please raise a JIRA issue for this? > > On 28/03/2014 11:59, Hans Schwäbli wrote: > > I could cache the embedder myself by using lazy initialization in my > class which extends JUnitStories. > > But that has a side effect: the meta filtering does not work then for some > unknown reason. > > > On Wed, Mar 26, 2014 at 8:54 AM, Hans Schwäbli < > bugs.need.love@gmail.com> wrote: > >> Hello Mauro, >> >> I stumbled upon a beheavior of this method: >> org.jbehave.core.ConfigurableEmbedder.configuredEmbedder() >> >> It always calls these methods when being called: >> >> embedder.useConfiguration(configuration()); >> >> embedder.useCandidateSteps(candidateSteps()); >> >> embedder.useStepsFactory(stepsFactory()); >> >> >> >> This had some unexpected side effects for me. For example I am logging >> which steps are being used. Since I call configuredEmbeder() multiple >> times, the method stepsFactory() is called multiple times. Even if I use >> just one instance of embedder it is called many times since the JBehave >> framework calls configuredEmbedder() many times. >> >> Maybe it wold be good if there is another method added to >> org.jbehave.core.ConfigurableEmbedder called "configureEmbedder" which >> actually configures the embedder every time when it is called. >> >> But the method "configuredEmbedder" should maybe be implemented with lazy >> initialization, so that the calls in its method are just executed once. >> >> What do you think about it? >> > > >
[jbehave-user] Re: Behavior of org.jbehave.core.ConfigurableEmbedder.configuredEmbedder()
I could cache the embedder myself by using lazy initialization in my class which extends JUnitStories. But that has a side effect: the meta filtering does not work then for some unknown reason. On Wed, Mar 26, 2014 at 8:54 AM, Hans Schwäbli wrote: > Hello Mauro, > > I stumbled upon a beheavior of this method: > org.jbehave.core.ConfigurableEmbedder.configuredEmbedder() > > It always calls these methods when being called: > > embedder.useConfiguration(configuration()); > > embedder.useCandidateSteps(candidateSteps()); > > embedder.useStepsFactory(stepsFactory()); > > > > This had some unexpected side effects for me. For example I am logging > which steps are being used. Since I call configuredEmbeder() multiple > times, the method stepsFactory() is called multiple times. Even if I use > just one instance of embedder it is called many times since the JBehave > framework calls configuredEmbedder() many times. > > Maybe it wold be good if there is another method added to > org.jbehave.core.ConfigurableEmbedder called "configureEmbedder" which > actually configures the embedder every time when it is called. > > But the method "configuredEmbedder" should maybe be implemented with lazy > initialization, so that the calls in its method are just executed once. > > What do you think about it? >
[jbehave-user] Behavior of org.jbehave.core.ConfigurableEmbedder.configuredEmbedder()
Hello Mauro, I stumbled upon a beheavior of this method: org.jbehave.core.ConfigurableEmbedder.configuredEmbedder() It always calls these methods when being called: embedder.useConfiguration(configuration()); embedder.useCandidateSteps(candidateSteps()); embedder.useStepsFactory(stepsFactory()); This had some unexpected side effects for me. For example I am logging which steps are being used. Since I call configuredEmbeder() multiple times, the method stepsFactory() is called multiple times. Even if I use just one instance of embedder it is called many times since the JBehave framework calls configuredEmbedder() many times. Maybe it wold be good if there is another method added to org.jbehave.core.ConfigurableEmbedder called "configureEmbedder" which actually configures the embedder every time when it is called. But the method "configuredEmbedder" should maybe be implemented with lazy initialization, so that the calls in its method are just executed once. What do you think about it?
Re: [jbehave-user] Unexpected resolving result of the parameter value
Hello Mauro, yes it is logical. But there are cases where it would be easier if the parameter parsing would be smart enough to interpret "homepage_" as "homepage_firefox" for example. I think it would be more flexible and possibly easy to implement in JBehave. Inside the parameter value JBehave could examine if there is a parameter inside it which it needs to resolve from the examples table and then do it. So it would be more flexible what one could do with parameters in the stories. 2014-03-14 21:06 GMT+01:00 Mauro Talevi : > Parameter values are always identified by surrounding spaces. That's > why it interprets the value as "homepage_". > > Your solutions seems the most logical one. > > On 14/03/2014 15:44, Hans Schwäbli wrote: > > I stumpled upon an issue where I cannot use the parameters as I expected. > > See the example below. The problem line is the one starting with "Then". > > Scenario: Create Screenshots > Given Browser is used > And Login with user Standard > Then I create a screenshot with name homepage_ > Examples: > |---| > |browser| > |---| > |CHROME | > |FIREFOX| > |IE | > |---| > I supposed that JBehave will pass "hompage_CHROME" into the step method. > But it passes "hompage_" instead. > > In the case above I can solve it in another way, like this: > > Scenario: Create Screenshots > Given Browser is used > And Login with user Standard > Then I create a screenshot with name > Examples: > |---|| > |browser|filename| > |---|| > |CHROME |homepage_chrome | > |FIREFOX|homepage_firefox| > |IE |homepage_ie | > |---|| > Can I mix hard coded parameter values in the steps together with > parameters orginating from an examples table? Is this possible somehow? > > I consider this just as nice to have of course, since in most cases it can > be solved in the above way. > > >
Re: [jbehave-user] JBehave learning curve
Hello Josef, I think the technical part of JBehave is really intended for software developers, so it requires that knowledge. JBehave is a tool with a lot of features and has its complexity. It is well designed, of good quality and free. So there are of course some drawbacks like little documentation. Anyone can participate in creating such documentation, and some people do. I personally would hope, that an official Wiki is established for JBehave. That could help to solve that. It cold be helpful if the documentation is clearly separated into a part for story writers with no programming skills and for step implementers (developers). I could establish that official Wiki if the JBehave owners agree, so that people can easily participate in creating missing documentation and updating it in a central place of knowledge. 2014-03-06 14:36 GMT+01:00 Josef Dietl : > Hi Janusz, > > > > Thanks for taking up this topic. I was having similar problems to get > started, and for organizational reasons, I couldn't approach the group. > > > > I don't mean to offend anybody. Everybody here is incredibly helpful, and > the software is really great. But the learning curve is wild. Given the > deep questions I saw here while lurking, I wasn't exactly inspired to step > up, despite all the helpful attitude of Mauro and everybody. > > > > A bit about myself: I'm not a full-time developer, I'm a project manager > with a passion for continuous improvement of our development practices. I'm > good enough to occasionally find something in a code review, to make a > prototype or an automated test, but my focus is on providing the optimal > environment for the development team so that *they* can maximize their > productivity. So in order to get them to look at JBehave and [T|AT|B]DD, I > had to learn Maven and set up JBehave on my own in a branch of the project > to demonstrate the value-add. > > > > To cut a long story short, once I was through, adding stories and tests on > top of the existing set-up was cool and convincing, but the path there > could have been smoother. > > > > When I was working for the W3C, we had a saying: make the simple things > simple and the hard things possible. JBehave doesn't exactly work like > that, but once I had reached the "hard" things, I also found traction in > the documentation and the sample projects. > > > > I don't have the role to suggest anything here, but I did ask myself > repeatedly whether it wouldn't be possible to be more explicit about the > first steps. Back then, I've tried my best here -> > http://digitaler-heimwerker.de/2012/10/26/howto-maven-spring-und-jbehave/(unfortunately > German). If a check with Google Translate suggests that this > is basically useful, I'd translate and tweak this and its sibling post > (below) as needed and contribute it. > > > > Re-reading the post, I find that I struggled most on these topics: > > 1.What is the *simplest* possible working configuration of JBehave? > (there's a description on the site, but no full example... what are the main > classes, what is their relationship to each other? What do I need to import > from where? Reverse-engineering the thinking steps from the example > projects just didn't work for me.) > > 2.Depending on JBehave configuration and Maven configuration: Where > do I have to put this file, the stories and the step implementations? > > 3.And then, specifically for my almost-simplest-possible set-up: how > does all this relate with Spring. > > > > In hindsight, the biggest problem was #2: Which file goes where... (or, more > precisely, as everything is configurable: which configuration determines > what goes where, and what are the defaults?) > > > > For a slightly more advanced topic, there's even a post in English: > http://digitaler-heimwerker.de/2013/03/04/mocking-file-access-for-testing-with-jbehave-and-easymock/ > > > > I hope this helps. JBehave is really great, and I hope this message is > advancing its progress. > > Thank you all for your great work! > > > > Best wishes, > > > > Josef > > > > *From:* Janusz Kowalczyk [mailto:kowalczykjan...@gmail.com] > *Sent:* Donnerstag, 6. März 2014 12:58 > *To:* user@jbehave.codehaus.org > *Subject:* [jbehave-user] Why JBehave repo examples and website are the > worst example of work ever created by the any of the open source > communitties? > > > > It's truly remarkable that I haven't gave up yet in my attempts to use > JBehave many after days wasted on trying to figure out how to run examples > give on the jbehave.org or the ones available in the project's repo. > > > > Does any of the project members heard of Developer Experience? > > Are there any chances that this will change in near future or this project > will keep to scare off more people? > > > > > > Cheers > > J >
[jbehave-user] Unexpected resolving result of the parameter value
I stumpled upon an issue where I cannot use the parameters as I expected. See the example below. The problem line is the one starting with "Then". Scenario: Create Screenshots Given Browser is used And Login with user Standard Then I create a screenshot with name homepage_ Examples: |---| |browser| |---| |CHROME | |FIREFOX| |IE | |---| I supposed that JBehave will pass "hompage_CHROME" into the step method. But it passes "hompage_" instead. In the case above I can solve it in another way, like this: Scenario: Create Screenshots Given Browser is used And Login with user Standard Then I create a screenshot with name Examples: |---|| |browser|filename| |---|| |CHROME |homepage_chrome | |FIREFOX|homepage_firefox| |IE |homepage_ie | |---|| Can I mix hard coded parameter values in the steps together with parameters orginating from an examples table? Is this possible somehow? I consider this just as nice to have of course, since in most cases it can be solved in the above way.
Re: [jbehave-user] Reporting step documentation
Hi Mauro, great! I created a Jira issue for this: http://jira.codehaus.org/i#browse/JBEHAVE-997 I will see if I can contribute to implementing this. First I have to solve the security problem which I have when trying to commit into a cloned JBehave on Github from the company I work for. 2014-02-27 19:20 GMT+01:00 Mauro Talevi : > Hi, > > There is currently no html report for the stepdocs but easy to do. > > Please raise a JIRA issue for it. Contributions most welcome it you feel > up to it. > > Cheers > > On 27 Feb 2014, at 14:45, Hans Schwäbli > wrote: > > Hello JBehave developers, > > JBehave supports step documentation which is a cool feature. If I add a > Javadoc comment to the method which implements a step, I can see that > comment in the JBehave editor when I use code completion. > > However this information is not integrated in the JBehave report. Or did I > overlook a way to configure that in order to integrate it? > > Would you suggest to create Javadoc HTML output in the classic way (with > Ant or whatever) in order to produce this kind of report? Or do you intend > to integrate step documentation into the JBehave report in a future version? > >
[jbehave-user] Project specific settings not persisted?
I use Eclipse Kepler and changed the JBehave story language from "en" to "de" in the project settings (not in the Eclipse preferences). I enabled project specific settings for my project in the JBehave project preferences. I supposed that this is saved in a [projectfolder]/.settings in a ".conf" file. But as it seems it is not persisted there. Because of that I cannot check that into the Subversion code repository. Everyone who checks this project out has to configure the story language because this setting is not contained in any .prefs file in the .settings folder. What seems to be persisted is only that project specific settings are enabled for JBehave preferences. But the chosen story language is not persisted. Is it not meant to be persisted?
[jbehave-user] Reporting step documentation
Hello JBehave developers, JBehave supports step documentation which is a cool feature. If I add a Javadoc comment to the method which implements a step, I can see that comment in the JBehave editor when I use code completion. However this information is not integrated in the JBehave report. Or did I overlook a way to configure that in order to integrate it? Would you suggest to create Javadoc HTML output in the classic way (with Ant or whatever) in order to produce this kind of report? Or do you intend to integrate step documentation into the JBehave report in a future version?
Re: [jbehave-user] SeleniumStepMonitor does not show up in JBehave 4.0 beta 4
The new ContextStepMonitor works with jbehave 3.9 I discovered now, but not
with 4.0-beta-4, at least not with the same code.
Maybe it is just because version 4 is still beta, or it has to be used in
another way than in 3.9. I suppose there will be an example project for
4.0, so that I then can see how to use it for that version when it is
released.
I will use jbehave 3.9 until then.
2014-02-24 9:44 GMT+01:00 Hans Schwäbli :
> I could run that CoreStories, but could not port the example to version
> jbehave-beta-4.
>
> The CoreStories example runs on version 3.10-SNAPSHOT which I cannot
> depend in Maven since it is not in the Maven repository.
>
> Maybe CoreStories works only for 3.10-SNAPSHOT?
>
> I have to figure this out. It is not so easy with stuggling with Maven and
> Java code at the same time to get it working.
>
>
> 2014-02-20 18:53 GMT+01:00 Mauro Talevi :
>
> CoreStories has a working example.
>>
>> On 20 Feb 2014, at 16:56, Hans Schwäbli
>> wrote:
>>
>> Yes, I want to show the running progress like I could do with
>> SeleniumStepMonitor.
>>
>> I try to figure out how to use that new way.
>>
>>
>> 2014-02-20 1:07 GMT+01:00 Mauro Talevi :
>>
>>> The SeleniumStepMonitor should be replaced by the ContextStepMonitor,
>>> now in core.
>>>
>>> What is the objective? Show the running progress?
>>>
>>> On 19/02/2014 16:34, Hans Schwäbli wrote:
>>>
>>> I am opening a new topic for the problem with the SeleniumStepMonitor
>>> in JBehave 4.0 beta 4 with JBehave-web 3.5.5 and 3.6-beta-1.
>>>
>>> It does not show up with that version. It works however with JBehave 3.9.
>>>
>>> I discovered that in method
>>> org.jbehave.core.embedder.PerformableTree.RunContext.scenarioSteps(Scenario,
>>> Map) a MatchingStepMonitor is used instead of the
>>> configured step monitor.
>>>
>>> It can be fixed by creating an anonymous class and overriding
>>> org.jbehave.core.steps.MarkUnmatchedStepsAsPending.collectScenarioSteps(List,
>>> Scenario, Map, StepMonitor)
>>>
>>> MarkUnmatchedStepsAsPending myStepCollector = new
>>> MarkUnmatchedStepsAsPending() {
>>> @Override
>>> public List
>>> collectScenarioSteps(List candidateSteps, Scenario
>>> scenario, Map parameters,
>>> StepMonitor stepMonitor) {
>>> return super.collectScenarioSteps(candidateSteps,
>>> scenario, parameters, *mySeleniumStepMonitor*);
>>> }
>>> };
>>> Then in the configuration I write: .useStepCollector(myStepCollector)
>>>
>>> It must be an older issue since month ago I had the same problem with
>>> JBehave 4.0 beta 3 and switched to version 3.9 because of that.
>>>
>>> Maybe it is a bug (or you can please tell me how to configure it
>>> properly for JBehave 4.x)?
>>>
>>>
>>>
>>
>
Re: [jbehave-user] SeleniumStepMonitor does not show up in JBehave 4.0 beta 4
I could run that CoreStories, but could not port the example to version
jbehave-beta-4.
The CoreStories example runs on version 3.10-SNAPSHOT which I cannot depend
in Maven since it is not in the Maven repository.
Maybe CoreStories works only for 3.10-SNAPSHOT?
I have to figure this out. It is not so easy with stuggling with Maven and
Java code at the same time to get it working.
2014-02-20 18:53 GMT+01:00 Mauro Talevi :
> CoreStories has a working example.
>
> On 20 Feb 2014, at 16:56, Hans Schwäbli
> wrote:
>
> Yes, I want to show the running progress like I could do with
> SeleniumStepMonitor.
>
> I try to figure out how to use that new way.
>
>
> 2014-02-20 1:07 GMT+01:00 Mauro Talevi :
>
>> The SeleniumStepMonitor should be replaced by the ContextStepMonitor,
>> now in core.
>>
>> What is the objective? Show the running progress?
>>
>> On 19/02/2014 16:34, Hans Schwäbli wrote:
>>
>> I am opening a new topic for the problem with the SeleniumStepMonitor
>> in JBehave 4.0 beta 4 with JBehave-web 3.5.5 and 3.6-beta-1.
>>
>> It does not show up with that version. It works however with JBehave 3.9.
>>
>> I discovered that in method
>> org.jbehave.core.embedder.PerformableTree.RunContext.scenarioSteps(Scenario,
>> Map) a MatchingStepMonitor is used instead of the
>> configured step monitor.
>>
>> It can be fixed by creating an anonymous class and overriding
>> org.jbehave.core.steps.MarkUnmatchedStepsAsPending.collectScenarioSteps(List,
>> Scenario, Map, StepMonitor)
>>
>> MarkUnmatchedStepsAsPending myStepCollector = new
>> MarkUnmatchedStepsAsPending() {
>> @Override
>> public List
>> collectScenarioSteps(List candidateSteps, Scenario
>> scenario, Map parameters,
>> StepMonitor stepMonitor) {
>> return super.collectScenarioSteps(candidateSteps,
>> scenario, parameters, *mySeleniumStepMonitor*);
>> }
>> };
>> Then in the configuration I write: .useStepCollector(myStepCollector)
>>
>> It must be an older issue since month ago I had the same problem with
>> JBehave 4.0 beta 3 and switched to version 3.9 because of that.
>>
>> Maybe it is a bug (or you can please tell me how to configure it properly
>> for JBehave 4.x)?
>>
>>
>>
>
Re: [jbehave-user] SeleniumStepMonitor does not show up in JBehave 4.0 beta 4
Yes, I want to show the running progress like I could do with
SeleniumStepMonitor.
I try to figure out how to use that new way.
2014-02-20 1:07 GMT+01:00 Mauro Talevi :
> The SeleniumStepMonitor should be replaced by the ContextStepMonitor,
> now in core.
>
> What is the objective? Show the running progress?
>
> On 19/02/2014 16:34, Hans Schwäbli wrote:
>
> I am opening a new topic for the problem with the SeleniumStepMonitor in
> JBehave 4.0 beta 4 with JBehave-web 3.5.5 and 3.6-beta-1.
>
> It does not show up with that version. It works however with JBehave 3.9.
>
> I discovered that in method
> org.jbehave.core.embedder.PerformableTree.RunContext.scenarioSteps(Scenario,
> Map) a MatchingStepMonitor is used instead of the
> configured step monitor.
>
> It can be fixed by creating an anonymous class and overriding
> org.jbehave.core.steps.MarkUnmatchedStepsAsPending.collectScenarioSteps(List,
> Scenario, Map, StepMonitor)
>
> MarkUnmatchedStepsAsPending myStepCollector = new
> MarkUnmatchedStepsAsPending() {
> @Override
> public List
> collectScenarioSteps(List candidateSteps, Scenario
> scenario, Map parameters,
> StepMonitor stepMonitor) {
> return super.collectScenarioSteps(candidateSteps,
> scenario, parameters, *mySeleniumStepMonitor*);
> }
> };
> Then in the configuration I write: .useStepCollector(myStepCollector)
>
> It must be an older issue since month ago I had the same problem with
> JBehave 4.0 beta 3 and switched to version 3.9 because of that.
>
> Maybe it is a bug (or you can please tell me how to configure it properly
> for JBehave 4.x)?
>
>
>
[jbehave-user] SeleniumStepMonitor does not show up in JBehave 4.0 beta 4
I am opening a new topic for the problem with the SeleniumStepMonitor in
JBehave 4.0 beta 4 with JBehave-web 3.5.5 and 3.6-beta-1.
It does not show up with that version. It works however with JBehave 3.9.
I discovered that in method
org.jbehave.core.embedder.PerformableTree.RunContext.scenarioSteps(Scenario,
Map) a MatchingStepMonitor is used instead of the
configured step monitor.
It can be fixed by creating an anonymous class and overriding
org.jbehave.core.steps.MarkUnmatchedStepsAsPending.collectScenarioSteps(List,
Scenario, Map, StepMonitor)
MarkUnmatchedStepsAsPending myStepCollector = new
MarkUnmatchedStepsAsPending() {
@Override
public List collectScenarioSteps(List
candidateSteps, Scenario scenario, Map parameters,
StepMonitor stepMonitor) {
return super.collectScenarioSteps(candidateSteps,
scenario, parameters, *mySeleniumStepMonitor*);
}
};
Then in the configuration I write: .useStepCollector(myStepCollector)
It must be an older issue since month ago I had the same problem with
JBehave 4.0 beta 3 and switched to version 3.9 because of that.
Maybe it is a bug (or you can please tell me how to configure it properly
for JBehave 4.x)?
Re: [jbehave-user] Adding timestamps to report
I tried it now on 4.0 beta 4. The precondition seems to use org.jbehave.core.reporters.StoryReporterBuilder.withCrossReference(new CrossReference()) when creating the org.jbehave.core.configuration.Configuration. Otherwise the two files xref.json and xref.xml are not created. But it is not how I thought it would be. I expected that I see the timestamps in the story report HTML. But there are no timstamps there. What is your concept behind the timestamps? Do I have to transform the xref.xml file myself into a HTML file in order to see the timestamps? By the way, my LocalFrameContextView is not shown anymore while executing the story with JBehave 4. Has something changed with how the StepMonitor is configured or something like that? It seems to use MatchingStepMonitor or NullStepMonitor instead of SeleniumStepMonitor. 2014-02-19 9:24 GMT+01:00 Mauro Talevi : > The step timings is a functionality already available in 4.x > http://jira.codehaus.org/browse/JBEHAVE-778 > > In 3.x it'd be rather complicated to do. Can you take the latest 4.0 > beta for a spin? > > > On 18/02/2014 14:46, Hans Schwäbli wrote: > >> I would like to add timestamps to the report logging, especially for the >> steps so that I can see when a step has started and how long it took to >> finish. >> What is the recommended way to accomplish this? >> Someone in this mailing list wrote to modify the Freemarker template >> which JBehave uses. But that solution seems not maintainable to me since I >> don't want to deal with that complexity just to add some timestamps to the >> report. I would rather don't use timestamps if I would have to touch the >> Freemarker templates of JBehave. >> > > > - > To unsubscribe from this list, please visit: > >http://xircles.codehaus.org/manage_email > > >
[jbehave-user] Adding timestamps to report
I would like to add timestamps to the report logging, especially for the steps so that I can see when a step has started and how long it took to finish. What is the recommended way to accomplish this? Someone in this mailing list wrote to modify the Freemarker template which JBehave uses. But that solution seems not maintainable to me since I don't want to deal with that complexity just to add some timestamps to the report. I would rather don't use timestamps if I would have to touch the Freemarker templates of JBehave.
Re: [jbehave-user] How to include stacktrace in test result report?
Thank you. 2014-02-13 15:50 GMT+01:00 Mauro Talevi : > Configuration.storyReporterBuilder().withFailureTrace(true) > > > > On 13 Feb 2014, at 13:41, Hans Schwäbli > wrote: > > > > If an exception occurs while a step is being executed, JBehave only > prints the type of exception and its message. > > > > It does not print the stacktrace, which could contain valuable > information to analyse the exception. > > > > Can I somehow configure JBehave so that it includes the stacktrace in > the test result report? > > - > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
[jbehave-user] How to include stacktrace in test result report?
If an exception occurs while a step is being executed, JBehave only prints the type of exception and its message. It does not print the stacktrace, which could contain valuable information to analyse the exception. Can I somehow configure JBehave so that it includes the stacktrace in the test result report?
Re: [jbehave-user] Problem with parameter injection when an examples table is used
Hi Mauro,
I created today an Jira issue for this:
http://jira.codehaus.org/i#browse/JBEHAVE-981
2014-02-07 20:56 GMT+01:00 Mauro Talevi :
> Hi,
>
> this is indeed one of the solutions.
>
> I agree that it would be more useful as a default. Please raise a JIRA
> issue for this and we'll add it to next release.
>
> Cheers
>
> On 7 Feb 2014, at 15:23, Hans Schwäbli
> wrote:
>
> As it seems it can be solved with configuring the MostUsefuleConfiguration
> like this:
> .useParameterControls(new
> ParameterControls().useDelimiterNamedParameters(true))
>
> It is even documented here:
> http://jbehave.org/reference/stable/parametrised-scenarios.html("Parametrisation
> by name delimiters").
>
> I think this should be the default, using delimeter named parameters.
>
>
> 2014-02-07 Hans Schwäbli :
>
>> I debugged it and as it seems, this method does not work as I would
>> expect it:
>> org.jbehave.core.steps.StepCreator.ParameterisedStep.parametriseStep()
>>
>> The "org.jbehave.core.annotations.Named" annotation supports only one
>> value. But in my use cases I need two values: "creditAccount" and
>> "debitAccount".
>>
>> What if you support using an regular expression for the @Named annotation
>> instead of allowing just one value?
>>
>> That could be one way to solve it. The method
>> "ParameterisedStep.parametriseStep()" would need to be adapted accordingly
>> to support that logic.
>>
>>
>> 2014-02-07 Hans Schwäbli :
>>
>> Hello Mauro,
>>>
>>> I took the time to create an example project for Eclipse so that you can
>>> reproduce it.
>>>
>>> I attached the zip file to this email. Hopfully it is passed to the
>>> mailing list. If not, I will have to upload it somewhere and tell you the
>>> download link.
>>>
>>> You will see that it is not working as I expect it.
>>>
>>> My intention is to use the data from the examples table to pass it into
>>> the step.
>>>
>>> I have to use two different variable names for the account number, since
>>> I use both credit account number and debit account number in the examples
>>> table. If I would only use one account number in the examples table it
>>> would pass the value into the method.
>>> But with the way how I tried to use it, "" and
>>> "" are passed into the step method instead of the actual
>>> values from the examples table.
>>>
>>> I hope you can help me to achieve my goal.
>>>
>>>
>>> 2014-02-06 Mauro Talevi :
>>>
>>> Hi
>>>>
>>>> what is the stated intention here? You want two steps to match the
>>>> same method with different parameter names?
>>>>
>>>> Can you please provide a sample project - inclusive of textual stories
>>>> and steps class that reproduces your issue?
>>>>
>>>> Thanks
>>>>
>>>>
>>>> On 06/02/2014 16:52, Hans Schwäbli wrote:
>>>>
>>>>> I have two steps like this with a examples table where the values are
>>>>> defined:
>>>>> Given the account data of is known
>>>>> Given the account data of is known
>>>>> First I tried this in the step class method for the two steps above:
>>>>> @Given("the account data of $debitAccount is known")
>>>>> It works only for the first of the two steps. But the second step gets
>>>>> value ">>>> from the examples table.
>>>>> So I changed the annotation to be like this:
>>>>> @Given("the account data of $acount is known")
>>>>> But this does not work for both steps above since "" and
>>>>> "" is passed into the method instead of the actual values.
>>>>> Then I tried it with an alias:
>>>>> @Given("the account data of is known")
>>>>> @Alias("the account data of is known")
>>>>> The result was that the story failed without showing me why (no
>>>>> exception or any meaningful message).
>>>>> I tried also some other things with no success. I use JBehave 3.9 by
>>>>> the way.
>>>>> Can you please tell me the solution?
>>>>>
>>>>
>>>>
>>>> -
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>
>>
>
Re: [jbehave-user] Problem with parameter injection when an examples table is used
As it seems it can be solved with configuring the MostUsefuleConfiguration
like this:
.useParameterControls(new
ParameterControls().useDelimiterNamedParameters(true))
It is even documented here:
http://jbehave.org/reference/stable/parametrised-scenarios.html("Parametrisation
by name delimiters").
I think this should be the default, using delimeter named parameters.
2014-02-07 Hans Schwäbli :
> I debugged it and as it seems, this method does not work as I would expect
> it: org.jbehave.core.steps.StepCreator.ParameterisedStep.parametriseStep()
>
> The "org.jbehave.core.annotations.Named" annotation supports only one
> value. But in my use cases I need two values: "creditAccount" and
> "debitAccount".
>
> What if you support using an regular expression for the @Named annotation
> instead of allowing just one value?
>
> That could be one way to solve it. The method
> "ParameterisedStep.parametriseStep()" would need to be adapted accordingly
> to support that logic.
>
>
> 2014-02-07 Hans Schwäbli :
>
> Hello Mauro,
>>
>> I took the time to create an example project for Eclipse so that you can
>> reproduce it.
>>
>> I attached the zip file to this email. Hopfully it is passed to the
>> mailing list. If not, I will have to upload it somewhere and tell you the
>> download link.
>>
>> You will see that it is not working as I expect it.
>>
>> My intention is to use the data from the examples table to pass it into
>> the step.
>>
>> I have to use two different variable names for the account number, since
>> I use both credit account number and debit account number in the examples
>> table. If I would only use one account number in the examples table it
>> would pass the value into the method.
>> But with the way how I tried to use it, "" and
>> "" are passed into the step method instead of the actual
>> values from the examples table.
>>
>> I hope you can help me to achieve my goal.
>>
>>
>> 2014-02-06 Mauro Talevi :
>>
>> Hi
>>>
>>> what is the stated intention here? You want two steps to match the
>>> same method with different parameter names?
>>>
>>> Can you please provide a sample project - inclusive of textual stories
>>> and steps class that reproduces your issue?
>>>
>>> Thanks
>>>
>>>
>>> On 06/02/2014 16:52, Hans Schwäbli wrote:
>>>
>>>> I have two steps like this with a examples table where the values are
>>>> defined:
>>>> Given the account data of is known
>>>> Given the account data of is known
>>>> First I tried this in the step class method for the two steps above:
>>>> @Given("the account data of $debitAccount is known")
>>>> It works only for the first of the two steps. But the second step gets
>>>> value ">>> from the examples table.
>>>> So I changed the annotation to be like this:
>>>> @Given("the account data of $acount is known")
>>>> But this does not work for both steps above since "" and
>>>> "" is passed into the method instead of the actual values.
>>>> Then I tried it with an alias:
>>>> @Given("the account data of is known")
>>>> @Alias("the account data of is known")
>>>> The result was that the story failed without showing me why (no
>>>> exception or any meaningful message).
>>>> I tried also some other things with no success. I use JBehave 3.9 by
>>>> the way.
>>>> Can you please tell me the solution?
>>>>
>>>
>>>
>>> -
>>> To unsubscribe from this list, please visit:
>>>
>>>http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>
Re: [jbehave-user] Problem with parameter injection when an examples table is used
I debugged it and as it seems, this method does not work as I would expect
it: org.jbehave.core.steps.StepCreator.ParameterisedStep.parametriseStep()
The "org.jbehave.core.annotations.Named" annotation supports only one
value. But in my use cases I need two values: "creditAccount" and
"debitAccount".
What if you support using an regular expression for the @Named annotation
instead of allowing just one value?
That could be one way to solve it. The method
"ParameterisedStep.parametriseStep()" would need to be adapted accordingly
to support that logic.
2014-02-07 Hans Schwäbli :
> Hello Mauro,
>
> I took the time to create an example project for Eclipse so that you can
> reproduce it.
>
> I attached the zip file to this email. Hopfully it is passed to the
> mailing list. If not, I will have to upload it somewhere and tell you the
> download link.
>
> You will see that it is not working as I expect it.
>
> My intention is to use the data from the examples table to pass it into
> the step.
>
> I have to use two different variable names for the account number, since I
> use both credit account number and debit account number in the examples
> table. If I would only use one account number in the examples table it
> would pass the value into the method.
> But with the way how I tried to use it, "" and
> "" are passed into the step method instead of the actual
> values from the examples table.
>
> I hope you can help me to achieve my goal.
>
>
> 2014-02-06 Mauro Talevi :
>
> Hi
>>
>> what is the stated intention here? You want two steps to match the same
>> method with different parameter names?
>>
>> Can you please provide a sample project - inclusive of textual stories
>> and steps class that reproduces your issue?
>>
>> Thanks
>>
>>
>> On 06/02/2014 16:52, Hans Schwäbli wrote:
>>
>>> I have two steps like this with a examples table where the values are
>>> defined:
>>> Given the account data of is known
>>> Given the account data of is known
>>> First I tried this in the step class method for the two steps above:
>>> @Given("the account data of $debitAccount is known")
>>> It works only for the first of the two steps. But the second step gets
>>> value ">> from the examples table.
>>> So I changed the annotation to be like this:
>>> @Given("the account data of $acount is known")
>>> But this does not work for both steps above since "" and
>>> "" is passed into the method instead of the actual values.
>>> Then I tried it with an alias:
>>> @Given("the account data of is known")
>>> @Alias("the account data of is known")
>>> The result was that the story failed without showing me why (no
>>> exception or any meaningful message).
>>> I tried also some other things with no success. I use JBehave 3.9 by the
>>> way.
>>> Can you please tell me the solution?
>>>
>>
>>
>> -
>> To unsubscribe from this list, please visit:
>>
>>http://xircles.codehaus.org/manage_email
>>
>>
>>
>
[jbehave-user] Problem with parameter injection when an examples table is used
I have two steps like this with a examples table where the values are
defined:
Given the account data of is known
Given the account data of is known
First I tried this in the step class method for the two steps above:
@Given("the account data of $debitAccount is known")
It works only for the first of the two steps. But the second step gets
value "" and
"" is passed into the method instead of the actual values.
Then I tried it with an alias:
@Given("the account data of is known")
@Alias("the account data of is known")
The result was that the story failed without showing me why (no exception
or any meaningful message).
I tried also some other things with no success. I use JBehave 3.9 by the
way.
Can you please tell me the solution?
[jbehave-user] Examples table best practice question
I am asking myself whether it is a good idea to use example tables all the time or only on demand. Lets take this scenario to illustrate the options: *Scenario:* Login *When* I login with username *Hans* and password *Swordfish* *Then* I am logged in and username *Hans* is displayed It could be possible to use an example table for it: *Scenario:* Login *When* I login with username ** and password ** *Then* I am logged in and username ** is displayed *Examples:* |--| |username|password | |--| |Hans|Swordfish| |--| The username is a bit redundant in the first example since it occurs two times and might have to be changed in two places. In the second example the redundancy is removed by using an examples table. The first scenario example is more readable I think, escpecially for non-programmers, since they don't have encounter variables there, wheras the second example is more maintainable. What would you do in such and similiar cases? Accept the redundancy or remove it wherever possible with an examples table?
Re: [jbehave-user] Limiting scope of steps possible?
Great idea, thank you!
As it seems the JBehave editor uses the input from the JUnitStory class.
We will try your solution.
2014-02-05 Bernardo Pinto :
> Yes, it is.
> Each one of your class that represents a story can extend JUnitStory.
> If you override the candidateSteps() method in the JUnitStory, you can add
> the step classes that you want. Something like this:
>
> abstract class StoryGroupOne extends JUnitStory {
> @Override
> public List candidateSteps() {
> return new InstanceStepsFactory(new StepsClassOne(), new
> StepsClassTwo()).createCandidateSteps();
> }
> }
>
> abstract class StoryGroupTwo extends JUnitStory {
> @Override
> public List candidateSteps() {
> return new InstanceStepsFactory(new StepsClassThree(), new
> StepsClassFour()).createCandidateSteps();
> }
> }
>
> public class StoryOne extends StoryGroupOne {}
> public class StoryTwo extends StoryGroupTwo {}
>
> This way, StoryOne only has access to the steps in StepsClassOne and
> StesClassTwo and StoryTwo only has access to steps in StepsClassThree and
> StepsClassFour.
>
>
> Bernardo Oliveira Pinto
> Byclosure, Lda.
> Mail: bernardo.pi...@byclosure.com
> Web: http://byclosure.com
>
>
> On Wed, Feb 5, 2014 at 10:55 AM, Hans Schwäbli <
> bugs.need.love@gmail.com> wrote:
>
>> The application under test contains several different functional modules
>> to test.
>>
>> These modules are tested by different testers.
>>
>> Currently, if a tester writes a JBehave story, the story editor proposes
>> all steps which exist for all modules.
>>
>> Is it possible to restrict which steps are proposed in JBehave so that
>> only steps for a specific module are valid to be used in a story for that
>> module?
>>
>> Of course we could create several Eclipse projects, each one for a
>> specific module of the application under test. But that seems to be over
>> engineered to me. If there is no other solution, we might have to go that
>> way.
>>
>> I am currently looking for a solution inside JBehave to limit the steps
>> which are accessible in the JBehave editor. For example, can steps be
>> categorized and be imported in the story, so that only imported steps are
>> valid? That would be one solution if that is possible.
>>
>> Any ideas which might help us to solve this?
>>
>
>
[jbehave-user] Limiting scope of steps possible?
The application under test contains several different functional modules to test. These modules are tested by different testers. Currently, if a tester writes a JBehave story, the story editor proposes all steps which exist for all modules. Is it possible to restrict which steps are proposed in JBehave so that only steps for a specific module are valid to be used in a story for that module? Of course we could create several Eclipse projects, each one for a specific module of the application under test. But that seems to be over engineered to me. If there is no other solution, we might have to go that way. I am currently looking for a solution inside JBehave to limit the steps which are accessible in the JBehave editor. For example, can steps be categorized and be imported in the story, so that only imported steps are valid? That would be one solution if that is possible. Any ideas which might help us to solve this?
Re: [jbehave-user] SeleniumStepMonitor could be more general
Hello Mauro, I created today such a Jira issue: http://jira.codehaus.org/browse/JBEHAVE-966 2013/12/6 Mauro Talevi > Hi Hans, > > Yes the context view and its local frame impl are indeed generic and could > be moved to core. > > please open a jira issue for this. > > In the meantime, you can use the classes in jbehave-selenium. > > Use the SeleniumStepMonitor with with the ContextView ctor. > > Cheers > > On 6 Dec 2013, at 13:12, Hans Schwäbli > wrote: > > You did not understand what I wrote about Christiano. > > It took me now some time to make sense of your postings, which actually > make no sense for my issue (sorry that I have to say that). > > After it took me quite a long time to get that example working I have > discovered that it has no StepMonitor like SeleniumStepMonitor. No window > appears when running the game-of-life story. I am a bit surprised how > someone can misunderstand my original posting so much. Anyway. > > The issue is still unresolved. I would be glad if someone can help me. > > The window which appears when using the SeleniumStepMonitor is very > helpful. But it should not be limited for Selenium but be more general in > my opinion, so that it can be used whenever someone wants to use JBehave > for UI testing. What do you think (not you Christiano ;-))? > > > 2013/12/5 Hans Schwäbli > >> Strange, since if I don't set any StepMonitor I don't see a StepMonitor >> like the SeleniumStepMonitor. Do you know how SeleniumStepMonitor appears? >> Maybe we have a misunderstanding. >> >> Anyway, I will check that. >> >> >> 2013/12/4 Cristiano Gavião >> >>> you can't see because the default StepMonitor (as many other configs) is >>> set automatically for JBehave runner/embedder. >>> >>> and this project is for test a Swing application >>> >>> >>> 2013/12/4 Hans Schwäbli >>> >>>> Could you be more specific please? >>>> >>>> If I look into this class, there is no StepMonitor configured: >>>> >>>> https://github.com/jbehave/jbehave-core/blob/master/examples/gameoflife/src/main/java/com/lunivore/gameoflife/GridStory.java >>>> >>>> >>>> 2013/12/4 Cristiano Gavião >>>> >>>>> You already have this in core... >>>>> >>>>> check this example: >>>>> https://github.com/jbehave/jbehave-core/tree/master/examples/gameoflife >>>>> >>>>> >>>>> 2013/12/4 Hans Schwäbli >>>>> >>>>>> There is a nice SeleniumStepMonitor in jbehave-web which shows live >>>>>> the steps which are performed in a small window. >>>>>> >>>>>> I tried to have such a step monitor in another use case: testing a >>>>>> rich client with JBehave and IBM Rational Functional Tester. >>>>>> >>>>>> It would be nice if I could use that monitoring window for this use >>>>>> case too. But SeleniumStepMonitor is only meant for Selenium. >>>>>> >>>>>> But I think it could be moved to core so that it can be used when >>>>>> automating any GUI, with or without Selenium >>>>>> >>>>>> I mean a general purpose "GuiStepMonitor" or something like this. So >>>>>> it could be used even if I don't use Selenium. >>>>>> >>>>>> What do you think? >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> "Tudo vale a pena se a alma não é pequena..." >>>>> >>>> >>>> >>> >>> >>> -- >>> "Tudo vale a pena se a alma não é pequena..." >>> >> >> >
Re: [jbehave-user] SeleniumStepMonitor could be more general
You did not understand what I wrote about Christiano. It took me now some time to make sense of your postings, which actually make no sense for my issue (sorry that I have to say that). After it took me quite a long time to get that example working I have discovered that it has no StepMonitor like SeleniumStepMonitor. No window appears when running the game-of-life story. I am a bit surprised how someone can misunderstand my original posting so much. Anyway. The issue is still unresolved. I would be glad if someone can help me. The window which appears when using the SeleniumStepMonitor is very helpful. But it should not be limited for Selenium but be more general in my opinion, so that it can be used whenever someone wants to use JBehave for UI testing. What do you think (not you Christiano ;-))? 2013/12/5 Hans Schwäbli > Strange, since if I don't set any StepMonitor I don't see a StepMonitor > like the SeleniumStepMonitor. Do you know how SeleniumStepMonitor appears? > Maybe we have a misunderstanding. > > Anyway, I will check that. > > > 2013/12/4 Cristiano Gavião > >> you can't see because the default StepMonitor (as many other configs) is >> set automatically for JBehave runner/embedder. >> >> and this project is for test a Swing application >> >> >> 2013/12/4 Hans Schwäbli >> >>> Could you be more specific please? >>> >>> If I look into this class, there is no StepMonitor configured: >>> >>> https://github.com/jbehave/jbehave-core/blob/master/examples/gameoflife/src/main/java/com/lunivore/gameoflife/GridStory.java >>> >>> >>> 2013/12/4 Cristiano Gavião >>> >>>> You already have this in core... >>>> >>>> check this example: >>>> https://github.com/jbehave/jbehave-core/tree/master/examples/gameoflife >>>> >>>> >>>> 2013/12/4 Hans Schwäbli >>>> >>>>> There is a nice SeleniumStepMonitor in jbehave-web which shows live >>>>> the steps which are performed in a small window. >>>>> >>>>> I tried to have such a step monitor in another use case: testing a >>>>> rich client with JBehave and IBM Rational Functional Tester. >>>>> >>>>> It would be nice if I could use that monitoring window for this use >>>>> case too. But SeleniumStepMonitor is only meant for Selenium. >>>>> >>>>> But I think it could be moved to core so that it can be used when >>>>> automating any GUI, with or without Selenium >>>>> >>>>> I mean a general purpose "GuiStepMonitor" or something like this. So >>>>> it could be used even if I don't use Selenium. >>>>> >>>>> What do you think? >>>>> >>>> >>>> >>>> >>>> -- >>>> "Tudo vale a pena se a alma não é pequena..." >>>> >>> >>> >> >> >> -- >> "Tudo vale a pena se a alma não é pequena..." >> > >
Re: [jbehave-user] SeleniumStepMonitor could be more general
Strange, since if I don't set any StepMonitor I don't see a StepMonitor like the SeleniumStepMonitor. Do you know how SeleniumStepMonitor appears? Maybe we have a misunderstanding. Anyway, I will check that. 2013/12/4 Cristiano Gavião > you can't see because the default StepMonitor (as many other configs) is > set automatically for JBehave runner/embedder. > > and this project is for test a Swing application > > > 2013/12/4 Hans Schwäbli > >> Could you be more specific please? >> >> If I look into this class, there is no StepMonitor configured: >> >> https://github.com/jbehave/jbehave-core/blob/master/examples/gameoflife/src/main/java/com/lunivore/gameoflife/GridStory.java >> >> >> 2013/12/4 Cristiano Gavião >> >>> You already have this in core... >>> >>> check this example: >>> https://github.com/jbehave/jbehave-core/tree/master/examples/gameoflife >>> >>> >>> 2013/12/4 Hans Schwäbli >>> >>>> There is a nice SeleniumStepMonitor in jbehave-web which shows live the >>>> steps which are performed in a small window. >>>> >>>> I tried to have such a step monitor in another use case: testing a rich >>>> client with JBehave and IBM Rational Functional Tester. >>>> >>>> It would be nice if I could use that monitoring window for this use >>>> case too. But SeleniumStepMonitor is only meant for Selenium. >>>> >>>> But I think it could be moved to core so that it can be used when >>>> automating any GUI, with or without Selenium >>>> >>>> I mean a general purpose "GuiStepMonitor" or something like this. So it >>>> could be used even if I don't use Selenium. >>>> >>>> What do you think? >>>> >>> >>> >>> >>> -- >>> "Tudo vale a pena se a alma não é pequena..." >>> >> >> > > > -- > "Tudo vale a pena se a alma não é pequena..." >
Re: [jbehave-user] SeleniumStepMonitor could be more general
Could you be more specific please? If I look into this class, there is no StepMonitor configured: https://github.com/jbehave/jbehave-core/blob/master/examples/gameoflife/src/main/java/com/lunivore/gameoflife/GridStory.java 2013/12/4 Cristiano Gavião > You already have this in core... > > check this example: > https://github.com/jbehave/jbehave-core/tree/master/examples/gameoflife > > > 2013/12/4 Hans Schwäbli > >> There is a nice SeleniumStepMonitor in jbehave-web which shows live the >> steps which are performed in a small window. >> >> I tried to have such a step monitor in another use case: testing a rich >> client with JBehave and IBM Rational Functional Tester. >> >> It would be nice if I could use that monitoring window for this use case >> too. But SeleniumStepMonitor is only meant for Selenium. >> >> But I think it could be moved to core so that it can be used when >> automating any GUI, with or without Selenium >> >> I mean a general purpose "GuiStepMonitor" or something like this. So it >> could be used even if I don't use Selenium. >> >> What do you think? >> > > > > -- > "Tudo vale a pena se a alma não é pequena..." >
Re: [jbehave-user] Re: JBehave Stories Best Practices?
Thank you for your responses. I don't know if the overhead of writing HTML
documentation (no Wiki exists instead) is too large for me. I will think
over it.
Currently it looks like this (just a draft to be discussed):
General:
- Use comments sparingly.
- Choose an appropriate language. If your requirements specification is
in French for instance and most of the business analysts, programmers and
testers speak French, write the stories in that language.
- Don't mix languages.
Stories:
- Stories may be dependent of each other. If so, they must declare their
dependencies in a machine executable way. When writing a story, always
assume that it will run against the system in a default, blank state.
- Stories should be repeatable, without having to clean up data manually
before it can be repeated for instance.
- A story typically has somewhere between five and twenty scenarios,
each describing different examples of how that feature should behave in
different circumstances.
- Prioritize your stories using meta information so that only high
priority stories can be executed if required.
- Categorize your stories.
Scenarios:
- Each scenario may be dependent by a previous scenario of the same
story.
- Each scenario typically has somewhere between 5 and 15 steps (not
considering step multiplication by example tables).
- A scenario should consist of steps of both types: action ("Given" or
"When") and verification ("Then").
- Each scenario, including example table, should not take too much time
to finish on a fast environment.
Steps:
- Simple Steps (not composed ones) of type "Given" and "When" should not
perform a verification and steps of type "Then" should not perform actions.
- Step names should not contain GUI information but be expressed in a
client-neutral way wherever possible. Instead of "Then a popup window
appears where a user can sign in" it would be better to use "Then the user
can sign in". Only use GUI words in step names if you intend to
specifically test the GUI layer.
- Step names should not contain technical details but be written in
business language terms.
- Use declarative style for your steps instead of imperative (see the
example in "The Cucumber Book" page 91-93).
- Avoid too detailed steps like "When user enters street name" if you
don’t intend to test the UI interaction.
- Don't use step aliases for different languages. Instead choose just
one language for all your stories.
- Use step name aliases sparingly.
2013/11/27 Mauro Talevi
> Hi Hans,
>
> thanks for starting this discussion. It is rather useful.
>
> I tend to agree with most of the points below but not all.
>
> Notably, I think stories should be independently executable, declaring via
> GivenStories all the preconditions they need. Scenarios are not
> necessarily independent and crucially will not always run against a blank
> state. That works for simple demo scenarios, but not for complex testing
> strategies.A scenario should declare its state and pre-condition (again
> via GivenStories, possibly selecting one specific scenario to depend on, or
> with the Lifecycle Before) when necessary (e.g. you could reset it), but it
> may also depend on the state of the previous scenario.
>
> Also, with regard to point 6, imposing an arbitrary time-limit on a
> scenario execution is not a priori recommendable. True, one needs to be
> aware of time issues because if execution takes too long it will not be
> performed as often as it should, but the time considerations are linked to
> the nature of the system under test. Some scenarios will run for longer
> than a few minutes. A better solution is to structure the running of
> stories in parallel when possible.
>
> If you want, you could start a new doc page contribution that we can
> evolve over time.
>
> Feel free to create a JIRA issue and provide a pull request to a new page
> in
> https://github.com/jbehave/jbehave-core/tree/master/distribution/src/site/content
>
> Cheers
>
>
> On 27/11/2013 07:58, Hans Schwäbli wrote:
>
> I would especially like to discuss this issue:
>
> *3. Each scenario must make sense and be able to be executed independently
> of any other scenario. When writing a scenario, always assume that it will
> run against the system in a default, blank state.*
>
> I quoted that from "The Cucumber Book". It sounds good initially, but I am
> not so sure about it. By the way, the system is nearly never in a "blank
> state", only in the very beginning after the first rollout.
>
> If this best practice is applied, it can cause too long story execution in
> some en
[jbehave-user] SeleniumStepMonitor could be more general
There is a nice SeleniumStepMonitor in jbehave-web which shows live the steps which are performed in a small window. I tried to have such a step monitor in another use case: testing a rich client with JBehave and IBM Rational Functional Tester. It would be nice if I could use that monitoring window for this use case too. But SeleniumStepMonitor is only meant for Selenium. But I think it could be moved to core so that it can be used when automating any GUI, with or without Selenium I mean a general purpose "GuiStepMonitor" or something like this. So it could be used even if I don't use Selenium. What do you think?
Re: [jbehave-user] Some interesting features I discovered for JBehave
I think I will wait a bit until creating an issue for the paramter validation with regular expressions. I must admit that I currently have no use case for it and need more JBehave experience to assess that. Concerning multiple example tables: this is really nice to have in my eyes, not more than that. 2013/11/27 Mauro Talevi > Hi, > > Parameter value validation could be a useful new feature if it was > configured via annotations.Feel free to raise a new JIRA issue for this > and to add some initial use cases. In particular sometime more than > simply it's a int or a String - because that already comes out of the box > with the strong typing in Java (which Ruby is missing).But further > validation, e.g. String formatting or other would be interesting to > consider. > > As for having multiple Examples tables, I'm still struggling to see the > benefit of this. Having multiple tables implicitly add complexity and > conventions on how to treat them. If there is not obvious benefit, then > it's not worth it. If anything, one could think about defining sub-parts > within the same table. Again, let's start by outlining the use case for > it. Always open to useful ideas. > > Thanks for contributing your ideas. Most appreciated. > > Cheers > > > On 27/11/2013 12:09, Hans Schwäbli wrote: > > Hello Mauro, > > thank you for your answer. > > 1. Sounds great! > > 2. I think it could be implemented in a way that story writers don't see > the regex but a parameter name. The regex would be contained just in the > step definition to provide an instant feedback in the story editor on > whether the paramter value is valid. Otherwise these kind of mistakes can > only be displayed later at the execution time of the story. But it is okay > for me. > > 3. I see. It was meant as "nice-to-have" maybe, it is not really required > as you said. > > Bye > > > 2013/11/27 Mauro Talevi > >> Hi Hans, >> >> thanks for your suggestions, always welcome. >> >> To answer your points: >> >> 1. JBehave now supports the Lifecycle Before and After syntax ( >> http://jira.codehaus.org/browse/JBEHAVE-906): >> >> http://jbehave.org/reference/preview/story-syntax.html >> >> Lifecycle Before is equivalent to Gherkin's background. >> >> You can try out this feature in the latest beta (3.9-beta-3). >> >> 2. JBehave parameters are implicitly validated by the fact that they >> correspond to strongly typed Java variables. JBehave does not expose the >> regex in the step patterns, as it's considered an implementation detail. >> Moreover as some scenario writers are non-technical it would be baffling to >> them (and not just to them - regex is not exactly a user-friendly syntax). >> >> 3. The examples table can be separated in groups by comment lines. >> >> Cheers >> >> >> On 27/11/2013 08:29, Hans Schwäbli wrote: >> >> I read a bit "The Cucumber Book" in order to find best practices when >> writing BDD tests. It is very similiar, so I could find some. >> >> When I read across the book, I discovered some cool features which might >> be good for JBehave too. >> >> >> *Background* >> >> For instance there is a feature called "Background". Here is the >> description from the book: >> >> *A background section in a feature file allows you to specify a set of >> steps that are common to every scenario in the file. Instead of having to >> repeat those steps over and over for each scenario, you move them up into a >> Background* >> *element. There are a couple of advantages to doing this:* >> >>- *If you ever need to change those steps, you have to change them in >>only one place.* >>- *The importance of those steps fades into the background so that >>when you’re reading each individual scenario, you can focus on what is >>unique and important about that scenario.* >> >> It seems to be the same concept like JUnit's @Before or even >> @BeforeClass. In JBehave you can do this with "GivenStories". But this is >> maybe not the same, if Background seems to be executed before each scenario >> starts. And the readability is better with a Background definition where >> you can read the steps in the same story file. >> >> But what is missing, even in Cucumber, is to declare in the story what >> happens after a scenario or a story has finished. In JUnit you have @After >> and @AfterClass for this purpose. This is typically used for clean-up and >&
Re: [jbehave-user] Some interesting features I discovered for JBehave
Hello Mauro,
thank you for your answer.
1. Sounds great!
2. I think it could be implemented in a way that story writers don't see
the regex but a parameter name. The regex would be contained just in the
step definition to provide an instant feedback in the story editor on
whether the paramter value is valid. Otherwise these kind of mistakes can
only be displayed later at the execution time of the story. But it is okay
for me.
3. I see. It was meant as "nice-to-have" maybe, it is not really required
as you said.
Bye
2013/11/27 Mauro Talevi
> Hi Hans,
>
> thanks for your suggestions, always welcome.
>
> To answer your points:
>
> 1. JBehave now supports the Lifecycle Before and After syntax (
> http://jira.codehaus.org/browse/JBEHAVE-906):
>
> http://jbehave.org/reference/preview/story-syntax.html
>
> Lifecycle Before is equivalent to Gherkin's background.
>
> You can try out this feature in the latest beta (3.9-beta-3).
>
> 2. JBehave parameters are implicitly validated by the fact that they
> correspond to strongly typed Java variables. JBehave does not expose the
> regex in the step patterns, as it's considered an implementation detail.
> Moreover as some scenario writers are non-technical it would be baffling to
> them (and not just to them - regex is not exactly a user-friendly syntax).
>
> 3. The examples table can be separated in groups by comment lines.
>
> Cheers
>
>
> On 27/11/2013 08:29, Hans Schwäbli wrote:
>
> I read a bit "The Cucumber Book" in order to find best practices when
> writing BDD tests. It is very similiar, so I could find some.
>
> When I read across the book, I discovered some cool features which might
> be good for JBehave too.
>
>
> *Background*
>
> For instance there is a feature called "Background". Here is the
> description from the book:
>
> *A background section in a feature file allows you to specify a set of
> steps that are common to every scenario in the file. Instead of having to
> repeat those steps over and over for each scenario, you move them up into a
> Background*
> *element. There are a couple of advantages to doing this:*
>
>- *If you ever need to change those steps, you have to change them in
>only one place.*
>- *The importance of those steps fades into the background so that
>when you’re reading each individual scenario, you can focus on what is
>unique and important about that scenario.*
>
> It seems to be the same concept like JUnit's @Before or even
> @BeforeClass. In JBehave you can do this with "GivenStories". But this is
> maybe not the same, if Background seems to be executed before each scenario
> starts. And the readability is better with a Background definition where
> you can read the steps in the same story file.
>
> But what is missing, even in Cucumber, is to declare in the story what
> happens after a scenario or a story has finished. In JUnit you have @After
> and @AfterClass for this purpose. This is typically used for clean-up and
> is executed even if the tests fails. The story knows best what it has to
> clean-up. But there needs to be a way how that clean-up per story is
> executed even if the story fails. I think even clean-ups per scenario would
> be good to have. I think I haven seen JBehave annotations for
> @AfterScenario and so on, but it is meant for something general which need
> to be done commonly for all scenarios. So it is not comparable to JUnit's
> concept and behavior of @After for instance.
>
>
> *Parameter Validation*
>
> Another nice feature I have discovered in Cucumber is that parameter's are
> validated by regular expressions. Here an example:
>
> @Given("I have deposited \$(\d+) in my (\w+) Account")
>
>
> *Grouping Examples*
>
> Yet another nice feature I have seen is to group examples:
>
> Examples: Successful withdrawal
> | Balance | Withdrawal | Outcome | Remaining |
> | $500| $50| receive $50 cash | $450 |
> | $500| $100 | receive $100 cash | $400 |
>
> Examples: Attempt to withdraw too much
> | Balance | Withdrawal | Outcome | Remaining |
> | $100| $200 | see an error message | $100 |
> | $0 | $50| see an error message | $0|
>
>
>
[jbehave-user] Some interesting features I discovered for JBehave
I read a bit "The Cucumber Book" in order to find best practices when
writing BDD tests. It is very similiar, so I could find some.
When I read across the book, I discovered some cool features which might be
good for JBehave too.
*Background*
For instance there is a feature called "Background". Here is the
description from the book:
*A background section in a feature file allows you to specify a set of
steps that are common to every scenario in the file. Instead of having to
repeat those steps over and over for each scenario, you move them up into a
Background*
*element. There are a couple of advantages to doing this:*
- *If you ever need to change those steps, you have to change them in
only one place.*
- *The importance of those steps fades into the background so that when
you’re reading each individual scenario, you can focus on what is unique
and important about that scenario.*
It seems to be the same concept like JUnit's @Before or even @BeforeClass.
In JBehave you can do this with "GivenStories". But this is maybe not the
same, if Background seems to be executed before each scenario starts. And
the readability is better with a Background definition where you can read
the steps in the same story file.
But what is missing, even in Cucumber, is to declare in the story what
happens after a scenario or a story has finished. In JUnit you have @After
and @AfterClass for this purpose. This is typically used for clean-up and
is executed even if the tests fails. The story knows best what it has to
clean-up. But there needs to be a way how that clean-up per story is
executed even if the story fails. I think even clean-ups per scenario would
be good to have. I think I haven seen JBehave annotations for
@AfterScenario and so on, but it is meant for something general which need
to be done commonly for all scenarios. So it is not comparable to JUnit's
concept and behavior of @After for instance.
*Parameter Validation*
Another nice feature I have discovered in Cucumber is that parameter's are
validated by regular expressions. Here an example:
@Given("I have deposited \$(\d+) in my (\w+) Account")
*Grouping Examples*
Yet another nice feature I have seen is to group examples:
Examples: Successful withdrawal
| Balance | Withdrawal | Outcome | Remaining |
| $500| $50| receive $50 cash | $450 |
| $500| $100 | receive $100 cash | $400 |
Examples: Attempt to withdraw too much
| Balance | Withdrawal | Outcome | Remaining |
| $100| $200 | see an error message | $100 |
| $0 | $50| see an error message | $0|
[jbehave-user] Re: JBehave Stories Best Practices?
I would especially like to discuss this issue:
*3. Each scenario must make sense and be able to be executed independently
of any other scenario. When writing a scenario, always assume that it will
run against the system in a default, blank state.*
I quoted that from "The Cucumber Book". It sounds good initially, but I am
not so sure about it. By the way, the system is nearly never in a "blank
state", only in the very beginning after the first rollout.
If this best practice is applied, it can cause too long story execution in
some environments. Each scenario has to create some data first (which can
be a lot) in order to perform the actual test.
The above mentioned best practice seems to make sense if you have control
over your test data in the database which the system under test (SUT)
accesses. Then you could create some basic test data set in the SUT for
various purposes and pick the ones in the stories from which you want to
start your test. So you could cherry pick some data where you can perform
some high level tests whichout first having to create the required data.
But if you have no control over that test data in the SUT, then you have to
create a lot of data in the scenarios first before you actually can perform
the actual test. This applies for instance if you have to use a copy of the
productive data as your test data. This data is created in a very complex
way with many subsystems, so there is no way to design a basic (common)
test data set for the tests.
So I thought that in this environment, where you have no control of the
test data set, it might be better that scenarios are not independent of
each in order to opmize story execution time and have less repetition of
data creation.
Maybe a solution would be a feature I have seen in Cucumber which is
similiar to a feature in JUnit. You can define a "Background" for all your
scenarios in Cubumber. This is a kind of test fixture or what you do in the
JUnit test method annotated with @BeforeClass or @Before. I could not
figure out if it behaves so that it is executed just once for all scenarios
or for each scenario. It would only be helpful for the problem which I
mentioned if it would be performed once for all scenarios (similar purpose
like @BeforeClass in JUnit).
What do you think about the problems I see with the best practice I
mentioned above and how would you solve it in a environment where you have
to use productive data as test data and have nearly no control over them?
2013/11/22 Hans Schwäbli
> I would like to discuss best practices in using JBehave/BDD concerning
> story writing. So I will assert some best practices now as a JBehave/BDD
> beginner.
>
> Some of them I discovered online (various sources). I left the
> justifications.
>
> How do you think about it? Do you have any additional best practices for
> story writing with JBehave?
>
>1. Stories may be dependent of each other. If so, they must declare
>their dependencies.
>2. Each story typically has somewhere between five and twenty
>scenarios, each describing different examples of how that feature should
>behave in different circumstances.
>3. Each scenario must make sense and be able to be executed
>independently of any other scenario. When writing a scenario, always assume
>that it will run against the system in a default, blank state.
>4. Each scenario typically has somewhere between 5 and 15 steps (not
>considering step multiplification by example tables).
>5. A scenario should consist of steps of both types: action ("Given"
>or "When") and verification ("Then").
>6. Each scenario, including example table, should not run longer than
>3 minutes.
>7. Steps of type "Given" and "When" should not perform a verification
>and steps of type "Then" should not perform actions.
>8. Step names should not contain GUI information but be expressed in a
>client-neutral way wherever possible. Instead of "*Then a popup window
>appears where a user can sign in*" it would be better to use "*Then
>the user can sign in*". Only use GUI words in step names if you intend
>to specifically test the GUI layer.
>9. Step names should not contain technical details but be written in
>business language terms.
>10. Use declarative style for your steps instead of imperative (see
>the example in "The Cucumber Book" page 91-93).
>11. Choose an appropriate language. If your requirements specification
>is in French for instance and most of the business analysts, programmers
>and testers speak French, write the stories in that language.
>12. Don't mix languages in stories.
>13. Use comments sparingly in stories.
>14. Avoid too detailed
[jbehave-user] JBehave Stories Best Practices?
I would like to discuss best practices in using JBehave/BDD concerning
story writing. So I will assert some best practices now as a JBehave/BDD
beginner.
Some of them I discovered online (various sources). I left the
justifications.
How do you think about it? Do you have any additional best practices for
story writing with JBehave?
1. Stories may be dependent of each other. If so, they must declare
their dependencies.
2. Each story typically has somewhere between five and twenty scenarios,
each describing different examples of how that feature should behave in
different circumstances.
3. Each scenario must make sense and be able to be executed
independently of any other scenario. When writing a scenario, always assume
that it will run against the system in a default, blank state.
4. Each scenario typically has somewhere between 5 and 15 steps (not
considering step multiplification by example tables).
5. A scenario should consist of steps of both types: action ("Given" or
"When") and verification ("Then").
6. Each scenario, including example table, should not run longer than 3
minutes.
7. Steps of type "Given" and "When" should not perform a verification
and steps of type "Then" should not perform actions.
8. Step names should not contain GUI information but be expressed in a
client-neutral way wherever possible. Instead of "*Then a popup window
appears where a user can sign in*" it would be better to use "*Then the
user can sign in*". Only use GUI words in step names if you intend to
specifically test the GUI layer.
9. Step names should not contain technical details but be written in
business language terms.
10. Use declarative style for your steps instead of imperative (see the
example in "The Cucumber Book" page 91-93).
11. Choose an appropriate language. If your requirements specification
is in French for instance and most of the business analysts, programmers
and testers speak French, write the stories in that language.
12. Don't mix languages in stories.
13. Use comments sparingly in stories.
14. Avoid too detailed steps like "*When user enters street name*".
15. Don't use step aliases for different languages. Instead choose just
one language for all your stories.
16. Use step name aliases sparingly.
17. Prioritize your stories using meta information so that only high
priority stories can be executed if required.
Re: [jbehave-user] Using inline comments in stories?
I see. Thank you for the quick response. I have created a Jira issue with an improvement suggestion (low priority): http://jira.codehaus.org/browse/JBEHAVE-962 2013/11/21 Mauro Talevi > Inline comments are not currently supported. > > On 21 Nov 2013, at 14:40, Hans Schwäbli > wrote: > > Is it possible to use inline comments in examples like below? > > *Examples:* > |accountNr |city | > |123 !-- private customer|Zuerich| > |312 |Zuerich| > |999 !-- company customer|Basel | > > The above example does not work, neither with !-- nor with |--. > > As it seems, comments can only start on a new line in JBehave. So a > workaround would be: > > *Examples:* > |accountNr |city | > !-- private customer > |123 |Zuerich| > |312 |Zuerich| > !-- company customer > |999 |Basel | > > But this is not so readable as the inline comments since it destroys the > layout of the example table quite a bit. > > Does it work to use inline comments? If yes, how? > > If now, what do you think about improving JBehave so that inline comments > can be used in stories? > >
[jbehave-user] No access to web page with mailing list
This page does not work since today: http://www.mail-archive.com/user@jbehave.codehaus.org/ Message is: "Forbidden. You don't have permission to access / user@jbehave.codehaus.org/ on this server."
[jbehave-user] Using inline comments in stories?
Is it possible to use inline comments in examples like below? *Examples:* |accountNr |city | |123 !-- private customer|Zuerich| |312 |Zuerich| |999 !-- company customer|Basel | The above example does not work, neither with !-- nor with |--. As it seems, comments can only start on a new line in JBehave. So a workaround would be: *Examples:* |accountNr |city | !-- private customer |123 |Zuerich| |312 |Zuerich| !-- company customer |999 |Basel | But this is not so readable as the inline comments since it destroys the layout of the example table quite a bit. Does it work to use inline comments? If yes, how? If now, what do you think about improving JBehave so that inline comments can be used in stories?
Re: [jbehave-user] JBehave vs Cucumber
Hello Andreas (Ebbert-Karroum), maybe you know the advantages of JBehave vs Cucumber and the main differences? 2013/11/13 Hans Schwäbli > I noticed that the comparison says that JBehave is a bit better than > Cucumber concerning documentation. I would doubt that since today I have > seen that 2 books on Cucumber exist. But I think many of the information in > it can be applied to JBehave as well since they seem to be similiar tools. > > > 2013/11/13 Karlsson Christian > >> Thanks Hans >> >> >> >> Checked it and will read it through. >> >> >> >> Regards, >> >> >> >> >> >> *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<https://wmail.cag.se/owa/redir.aspx?C=G2EjVQkj7kGZyieqy24uGB6NV2uAkM9Iy3xqV4cZFUaEVGXCGlWIq_V5O25t1jIUtjHgAaGFl0U.&URL=http%3a%2f%2fwww.cag.se%2f> >> >> >> >> *Från:* Hans Schwäbli [mailto:bugs.need.love@gmail.com] >> *Skickat:* den 13 november 2013 10:33 >> *Till:* user@jbehave.codehaus.org >> *Ämne:* Re: [jbehave-user] JBehave vs Cucumber >> >> >> >> I don't know Cucumber but a few month ago I read this comparison: >> http://mkolisnyk.blogspot.ch/2013/03/jbehave-vs-cucumber-jvm-comparison.html >> >> >> >> 2013/11/12 Karlsson Christian >> >> Hi People >> >> >> >> I recently presented JBehave as a user acceptance automation tool to my >> colleagues. One of my colleagues then did the similar regarding Cucumber. >> Several members of the audience then wondered about the upsides/downsides >> of the aforementioned tools with respect to each other and we couldn’t >> really give a proper answer. >> >> What do you guys think are the advantages/disadvantages of JBehave over >> Cucumber? >> >> >> >> Thx, >> >> 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<https://wmail.cag.se/owa/redir.aspx?C=G2EjVQkj7kGZyieqy24uGB6NV2uAkM9Iy3xqV4cZFUaEVGXCGlWIq_V5O25t1jIUtjHgAaGFl0U.&URL=http%3a%2f%2fwww.cag.se%2f> >> >> >> >> >> > >
[jbehave-user] JUnit result is OK although JBehave story failed
Is it a normal behavior that the JUnit result sometimes differ from the JBehave result? If I run the stories with as JUnitStories within Eclipse it can be that the JUnit result is green but that there are failures in the JBehave result (steps which failed). If it is not considered normal, I will try to describe it if it occurs next time or give you information on how to reproduce it.
[jbehave-user] About a configuration method
I would like to ask a question about this method: org.jbehave.core.ConfigurableEmbedder.configuration(). Sometimes errors can occur if always a new instance of this object is returned, for example new report format objects are created. This is why they are constants in org.jbehave.core.reporters.Format I suppose. As it seems, JBehave calls the configuration() method multiple times while it executes stories. If it would only call it once, then no singletons would be required like the formats and no JBehave user could be trapped by this. The JBehave examples always return a new configuration object, which can be tricky, since it can cause errors. So I want to ask two things: Why does JBehave call configuration() method multiple times? Maybe it would be better to call it just once. And: If it needs to call it multiple times, would it be better if the JBehave examples in Github would return the same configuration instance instead of returning a new one each time?
