Hi Brian,
I'm now able to reproduce behaviour - I think I was misled by the noise
of debug :-)
I've pushed a change by which the non-working scenario is skipped until
we get it working.
The problem with it is that you want to reuse the same parameter names
in the two tables. To me it's all a bit confusing.
While it may be a legitimate request, I wouldn't consider it a bug,
rather an enhancement or a new usecase. In fact, you can get it to
work by using unique names.
Can we please try to reproduce the desired behaviour in the
parametrised_table.story? The bare-bone essential feature only.
For the time being, I would suggest you could change the language to
something along the lines of :
Given the users for Microsoft with properties: username,
passwordCleartext, enabled, expired, forcePasswordChange
Thus avoiding the double table - which feels a bit redundant here in any
case.
Cheers
On 28/02/2012 03:48, Brian Repko wrote:
Mauro,
Here are my settings
brian@brian-laptop:~/Projects/jbehave/jbehave-core/examples/spring-security$
mvn -version
Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600)
Maven home: /opt/apache-maven-3.0.3
Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-sun-1.6.0.26/jre
Default locale: en_US, platform encoding: UTF-8
I'm running with mvn clean install at this point against both 3.5.4
and 3.6-SNAPSHOT with the expected errors.
Just reconfigured logging and re-ran after rebuilding jbehave from
source as well as running the examples.
Completely turned off view generation. They do run at
integration-test maven phase.
Just to confirm - there are 6 examples in the failing scenario so when
you say that you are getting a failure
from the one that works - you are looking far enough up the list.
https://github.com/brianrepko/jbehave-core/commit/bad86e263fba6bd2c8b43ec90ed4d7174274a2b2
Help me understand what you are seeing...
At this point, I think I just log the bug
Brian
----- Original message -----
From: "Brian Repko" <brian.re...@learnthinkcode.com
<mailto:brian.re...@learnthinkcode.com>>
To: dev@jbehave.codehaus.org <mailto:dev@jbehave.codehaus.org>
Date: Mon, 27 Feb 2012 10:20:28 -0600
Subject: Re: [jbehave-dev] potential bug?
I'm running on Ubuntu Linux with Maven 3.0.3, Oracle JDK 1.6.0_29,
same local and encoding.
What is the specific error that you are getting? You mentioned that it
had something to do with the the behaviors run as unit tests.
They should be running at the integration-test phase, IIRC. But I can
check that tonight.
B
----- Original message -----
From: "Mauro Talevi" <mauro.tal...@aquilonia.org
<mailto:mauro.tal...@aquilonia.org>>
To: dev@jbehave.codehaus.org <mailto:dev@jbehave.codehaus.org>
Date: Mon, 27 Feb 2012 15:50:27 +0100
Subject: Re: [jbehave-dev] potential bug?
Brian,
failures do not depend on the version of JBehave. Get same error with
3.5.4
Here's my config:
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: /Users/mauro/applications/mvn
Java version: 1.6.0_29, vendor: Apple Inc.
Java home:
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.6.8", arch: "x86_64", family: "mac"
On 27/02/2012 15:08, Brian Repko wrote:
Yep - ran them with "mvn -Djbehave.version=3.5.4 clean install"
I can change the logging on Hibernate, yes.
If you are having a problem with the latest jbehave snapshot, that
may point to a regression error.
I'll have access to the laptop tonight to look at this.
Brian
----- Original message -----
From: "Mauro Talevi" <mauro.tal...@aquilonia.org
<mailto:mauro.tal...@aquilonia.org>>
To: dev@jbehave.codehaus.org <mailto:dev@jbehave.codehaus.org>
Date: Mon, 27 Feb 2012 09:51:39 +0100
Subject: Re: [jbehave-dev] potential bug?
Hi Brian,
Still fails - the problem is that the behaviours are run via unit
tests. I'm using mvn 3.x using latest snapshot of JBehave.
Are you able to run it from command-line?
Also, could you move to DEBUG in the logging all the noise from
Hibernate? I think it's not very informative as default.
Thanks
On 26/02/2012 22:43, Brian Repko wrote:
Mauro,
Apparently I need up to update the view generation.
I changed the ignoreErrorsInView - set to true - that now only shows
the one story with an error - when run against 3.5.4
https://github.com/brianrepko/jbehave-core/commit/515aba3e7aef19781b43da5263f64e518bc7094c
Brian
----- Original message -----
From: "Mauro Talevi" <mauro.tal...@aquilonia.org
<mailto:mauro.tal...@aquilonia.org>>
To: dev@jbehave.codehaus.org <mailto:dev@jbehave.codehaus.org>
Date: Sat, 25 Feb 2012 16:09:07 +0100
Subject: Re: [jbehave-dev] potential bug?
Hi Brian,
I'm not able to get the example scenario working (even the one that
should).
Would you be able to reproduce your issue using the
parametrised_table.story (note that I've updated it to not use <>
delimiters anymore).
Cheers
On 24/02/2012 15:59, Brian Repko wrote:
Mauro,
https://github.com/brianrepko/jbehave-core/commit/779c677199559d97818b567a7172f0afbd229414
This is the latest commit with both working and failing scenarios.
Thanks!
Brian
----- Original message -----
From: "Brian Repko" <brian.re...@learnthinkcode.com
<mailto:brian.re...@learnthinkcode.com>>
To: dev@jbehave.codehaus.org <mailto:dev@jbehave.codehaus.org>
Date: Fri, 24 Feb 2012 08:16:32 -0600
Subject: Re: [jbehave-dev] potential bug?
Mauro,
A working example - where my description ends - can be found at
https://github.com/brianrepko/jbehave-core
In user_flags.story you'll see the duplicate columns and changed
names to avoid the situations below.
Wasn't sure if you want fail state or working state...
Brian
----- Original message -----
From: "Mauro Talevi" <mauro.tal...@aquilonia.org
<mailto:mauro.tal...@aquilonia.org>>
To: "dev@jbehave.codehaus.org <mailto:dev@jbehave.codehaus.org>"
<dev@jbehave.codehaus.org <mailto:dev@jbehave.codehaus.org>>
Date: Thu, 23 Feb 2012 19:02:01 +0100
Subject: Re: [jbehave-dev] potential bug?
Hi Brian,
Could you please provide a version of te spring security example
that reproduces the problem and we can pull? Possibly with a
working version of stories/steps and a failing version.
Cheers
On 23 Feb 2012, at 18:16, Brian Repko
<brian.re...@learnthinkcode.com
<mailto:brian.re...@learnthinkcode.com>> wrote:
JBehave devs:
We have the following example story (acutally changing the story
in the spring-security example to be parameterized).
This is a parameterized scenario - that also include an Examples
Table parameter on the Given step.
The problem is that the ExamplesTable values are including the "<"
and ">" delimiters. This is due to how JBehave
expects the Examples: header values to be - for variables to be
replaced in steps - one does NOT include the <> - but
for values to be replaced in ExamplesTables - one does include the
<>. You can see this in the trader stories -
parameterized_table.story and any of the other parameterized
scenario stories.
Tried creating duplicate columns - username and <username> and
password and <password> (and renaming those
used in the table to get the <> around them) - that is not working
however as the replacement of username takes
precedence over <username> and I get "<testDisabled>" and
"<dpassword>" as values in the ExamplesTable still.
I then tried renaming the tables values with "_t" added to the end
(<username_t> and <password_t>) but that doesn't
work as the ExamplesTable now comes in with values
"<testDisabled_t>" and "<dpassword_t>". Also tried with the
"t_" as a prefix and that did the same.
Eventually had to rename them so that I had "username" and
"<user>" and "password" and "<pwd>". That worked.
But again with duplicate columns of data.
There seems to be bugs related to how NamedParameters get replaced
into the ExamplesTable.
Thoughts? Can I not use scenario parameters on BOTH a table and
steps?
Brian
---
Scenario: Test all the user flag combinations
Given the users for Microsoft:
|username|passwordCleartext|enabled|expired|forcePasswordChange|
|<username>|<password>|<enabled>|<expired>|<forcePasswordChange>|
When user <username> authenticates on <orgName> site with password
<password>
Then user should not be authenticated
And authentication failure is <failure>
Examples:
|orgName|username|password|enabled|expired|forcePasswordChange|failure|
|Microsoft|testDisabled|dpassword|false|false|false|Disabled|
|Microsoft|testExpired|epassword|true|true|false|AccountExpired|
|Microsoft|testDisabledAndExpired|depassword|false|true|false|Disabled|
|Microsoft|testFPCDisabled|fdpassword|false|false|true|Disabled|
|Microsoft|testFPCExpired|fepassword|true|true|true|AccountExpired|
|Microsoft|testFPCDisabledAndExpired|fdepassword|false|true|true|Disabled|
---
