[ 
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


Reply via email to