Re: [jbehave-user] Filtering works not as expected with a scenario containing an examples table

2014-05-20 Thread Mauro Talevi

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 
bugs.need.love@gmail.com mailto:bugs.need.love@gmail.com:


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 mailto: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-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
mauro.tal...@aquilonia.org
mailto:mauro.tal...@aquilonia.org 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
mauro.tal...@aquilonia.org
mailto:mauro.tal...@aquilonia.org 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
bugs.need.love@gmail.com
mailto:bugs.need.love@gmail.com 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
mailto: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 

Re: [jbehave-user] JBehave Preferences

2014-05-20 Thread Mauro Talevi
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] JBehave Preferences

2014-05-20 Thread Hans Schwäbli
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 mauro.tal...@aquilonia.orgwrote:

 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