[
https://jira.codehaus.org/browse/JBEHAVE-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295272#comment-295272
]
Mauro Talevi commented on JBEHAVE-748:
--------------------------------------
Yes, that is my question as well.
The principle underlying the current behaviour is the "out-in", i.e. any named
parameter specified in the table will override a matched parameter. You are
free to use multiple parameters for different scopes, e.g. matched parameters
for normal steps and named parameters for parametrised scenarios (i.e. using
examples tables).
There is a fundamental difference between matched parameters (i.e. using the
$name notation) and any other convention, e.g. <a> and <b>. The latter is only
used to match the step to the method but then the parameters are passed by
name, using the @Named annotation.
As of 3.6, there is a new behaviour whereby the parametrisation can be done
also by delimited named convention without @Named annotations (JBEHAVE-720).
So, I'm not sure where we stand with this issue. Is there an enhancement that
you'd like to propose? A clarification of the docs?
> When @Named parameter matches name in Example table, it might be injected for
> steps that do not reference it
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBEHAVE-748
> URL: https://jira.codehaus.org/browse/JBEHAVE-748
> Project: JBehave
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.5.4
> Environment: Windows 7, Java 6
> Reporter: Arjan van Bentem
>
> When a step with @Named parameters is used in a scenario that uses an Example
> table for SOME of its steps, but for this specific step is given some
> explicit value, then IF the parameter name is not fully surrounded with
> whitespace AND it matches a name from the Examples table, then the given
> value is ignored. Instead, the value from the Examples table is injected.
> If the parameter name is unrelated to anything in the Examples table, then
> all is fine, even when the parameter is not fully surrounded with whitespace.
> (This is slightly related to http://jira.codehaus.org/browse/JBEHAVE-646)
> For example, all fine:
> {code}
> @Given("I have <a> and <b>")
> public void givenAAndB(@Named("a") String myA, @Named("b") String myB) {
> assertThat(myA).isEqualTo("this");
> assertThat(myB).isEqualTo("that");
> }
> @When("I do <a>")
> public void whenIDoA(@Named("a") String myA) {
> assertThat(myA).isEqualTo("this");
> }
> @Then("I see <b>")
> public void thenISeeB(@Named("b") String myB) {
> assertThat(myB).isEqualTo("that");
> }
> // $x not surrounded by all whitespace, but "x" NOT known in Examples table:
> all fine
> @When("I did '$x'")
> public void whenIDidX(@Named("x") String myX) {
> assertThat(myX).isEqualTo("foo");
> }
> {code}
> ...but wrong:
> {code}
> // $b not surrounded by all whitespace, and "b" also known in Examples table
> @Then("I saw '$b'")
> public void thenISawB(@Named("b") String myB) {
> // Will fail: is assigned "that" from Examples table instead
> assertThat(myB).isEqualTo("bar");
> }
> {code}
> ...when used with:
> {code}
> Given I have <a> and <b>
> When I did 'foo'
> And I do <a>
> Then I see <b>
> And I saw 'bar'
> Examples:
> | a| b|
> |this|that|
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
