It is neither a bug nor the intended behaviour. It's simply the
behaviour that has satisfied the requirements up to now.
For starters, you can already leverage the delimited names, i.e. you
don't need to use @Alias and @Named:
|configuration.useParameterControls(||new|
|ParameterControls().useDelimiterNamedParameters(||true||));|
http://jbehave.org/reference/stable/parametrised-scenarios.html
Secondly, evolving a functionality does not mean necessarily adding an
alternative notation. Simply understanding the requirements and seeing
how they can be satisfied.
At the moment, for each parametrised scenario, there is a well defined
set of parameters - each identified by their names - and we use the same
set to match all the steps required.
Implicitly, there is the assumption that each different step can only be
matched and executed once, for a given set of values.
What we need to investigate is how this assumption can be relaxed.
So, as already set, let's start by collecting the usecases and the
requirements, with examples to show how it's meant to work.
Cheers
On 19/09/2014 18:37, Anders wrote:
If this is not a bug, then this is the intended behavior (by definition).
Can someone please explain the benefits of this behavior?
If we need to keep the current behavior while "evolving" this
functionality, then we would need to add an /alternate notation/ where
the column name in the examples table does not leak down to the
parameter name in the step implementation.
Maybe a notation like this would work?
(using Ayesha's example):
Given a user open homepage
Then should see ${message1}
When user do something and go to another page
Then should see ${message2}
*Examples:*
|message1|message2|
|Welcome|Hello|
Also, it would be more consistent if the declaration in the step
implementation did not have to specify if the value comes from a
literal or through a reference to the examples table.
Today, if I want to be able to call the same step implementation using
either a literal or a reference to an examples table, I have to add an
alias like this:
@Then("should see <message>")
@Alias("should see $message")
*public**void*shouldSeeMsg(@Named("message")String message)
{
// check text...
}
Instead, I think we should be able to do it this way:
@Then("should see $message")
*public**void*shouldSeeMsg(String message)
{
// check text...
}
And then use the step either way we like:
Given a user open homepage
Then should see Welcome
When user do something and go to another page
Then should see ${message2}
*Examples:*
|message2|
|Hello|
(specifying a literal in the first call ("Welcome"), and specifying a
reference to the example table in the second call.)
Cheers
*From:*Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
*Sent:* den 19 september 2014 17:36
*To:* user@jbehave.codehaus.org
*Subject:* Re: [jbehave-user] Parametrised scenario problem
It's not a bug, it's the current behaviour of the system. Nothing
prevents us from evolving this behaviour.
Feel free to raise the JIRA issue, describing how you'd like to see it
evolve.
Cheers
On 19/09/2014 16:12, Anders wrote:
I would argue that this is a serious bug, a bug that has been
there for a long time.
This strange "lock down" of parameter names when using example
tables has annoyed me for a long time.
This bug is seriously limiting the reusability of step methods.
Is there an issue for this in Jira that we can vote on?
*From:*Zheng, Ayesha(AWF) [mailto:xuzh...@ebay.com]
*Sent:* den 19 september 2014 11:24
*To:* user@jbehave.codehaus.org <mailto:user@jbehave.codehaus.org>
*Subject:* [jbehave-user] Parametrised scenario problem
Hi all,
I have a scenario:
Given a user open homepage
Then should see <message1>
When user do something and go to another page
Then should see <message2>
*Examples:*
test.table
And test.table with content:
|message1|message2|
|Welcome|Hello|
And step "Then should see <message1>" and "Then should see
<message2>" do the same thing: just check the text.
So I just want to implement it once time.
Code like:
@Then("should see <message>")
*public**void*shouldSeeMsg(@Named("message")String message)
{
// check text...
}
When running this case, I hope it can match both step "<message1>"
and "<message2>".
But the problem is, I found the parameter name in code must be the
same with the name specified in scenario.
These steps always in PENDING status.
Could anyone help to how to solve this?
Thanks very much.
Best Regards,
Ayesha
