[ 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