[
https://jira.codehaus.org/browse/JBEHAVE-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295002#comment-295002
]
Arjan van Bentem edited comment on JBEHAVE-748 at 3/24/12 5:06 AM:
-------------------------------------------------------------------
For 3.6-SNAPSHOT, things seem to be worse. Even when fully surrounded with
whitespace, it seems the values from any {{Examples:}} table are always
preferred, if a parameter name happens to match a name from such {{Examples:}}
table.
For 3.6-SNAPSHOT:
{code}
@Test
public void shouldNotCreateStepFromTableValuesViaAnnotations() throws Exception
{
StoryReporter reporter = mock(StoryReporter.class);
AnnotationNamedParameterSteps steps = new AnnotationNamedParameterSteps();
// Parameter values from an Examples table should NOT be used when the step
// does not refer to <ith> and <nth> but gives specific values instead. But
// in 3.5.4 and 3.6 SNAPSHOT the specific values are ignored if they happen
// to use the same name as used in the Examples table.
// When removing the next two lines, or when using a different name for
// BOTH "ith" and "nth", then all is fine. (In 3.5.4, only "ith" needs to
// be removed or renamed; in 3.6-SNAPSHOT both.)
namedParameters.put("ith", "top");
namedParameters.put("nth", "penthouse");
// In 3.5.4, even with the above namedParameters as provided, the following
// pattern only failed when some non-whitespace followed the parameter, like
// when adding a comma after "$ith":
// String patternAsString = "I live on the $ith, but some call it the
$nth";
// In 3.6-SNAPSHOT, this fails without that comma too, and also for $nth:
String patternAsString = "I live on the $ith floor but some call it the
$nth";
Method method = stepMethodFor("methodWithNamedParametersInNaturalOrder",
AnnotationNamedParameterSteps.class);
StepCandidate candidate = candidateWith(patternAsString, WHEN, method,
steps);
StepResult result =candidate.createMatchedStep("When I live on the first
floor but some call it the ground", namedParameters)
.perform(null);
// Will fail in both 3.5.4 and in 3.6-SNAPSHOT:
// java.lang.AssertionError: Expected: "first" got: "top"
assertThat(steps.ith, equalTo("first"));
// Will fail in 3.6-SNAPSHOT:
// java.lang.AssertionError: Expected: "ground" got: "penthouse"
assertThat(steps.nth, equalTo("ground"));
result.describeTo(reporter);
verify(reporter).successful(
"When I live on the " + PARAMETER_VALUE_START + "first" +
PARAMETER_VALUE_END + " floor but some call it the " + PARAMETER_VALUE_START +
"ground" + PARAMETER_VALUE_END );
}{code}
In 3.5.4,
{{org.jbehave.core.parsers.RegexPrefixCapturingPatternParser#findParametersToReplace}}
finds {{ith,}} (including the comma) and {{nth}} as the parameter names. In
3.6 SNAPSHOT,
{{org.jbehave.core.parsers.RegexPrefixCapturingPatternParser.Parameter}} has
changed, and (correctly) finds {{ith}} and {{nth}}. But still the values from
the {{Examples:}} table overwrite both.
was (Author: avbentem):
For 3.6-SNAPSHOT, things seem to be worse. Even when fully surrounded with
whitespace, it seems the values from any {{Examples:}} table are always
preferred, if a parameter name happens to match a name from such {{Examples:}}
table.
For 3.6-SNAPSHOT:
{code}
@Test
public void shouldNotCreateStepFromTableValuesViaAnnotations() throws Exception
{
StoryReporter reporter = mock(StoryReporter.class);
AnnotationNamedParameterSteps steps = new AnnotationNamedParameterSteps();
// Parameter values from an Examples table should NOT be used in this test.
// When removing the next two lines, or when using a different name for
// BOTH "ith" and "nth", then all is fine. (In 3.5.4, only "ith" needs to
// be removed or renamed; in 3.6-SNAPSHOT both!)
namedParameters.put("ith", "top");
namedParameters.put("nth", "penthouse");
// In 3.5.4, even with the above namedParameters as provided, the following
// pattern worked fine if $ith was fully surrounded with whitespace, like:
// String patternAsString = "I live on the $ith but some call it the
$nth";
// (but not when a comma follows the parameter name). In 3.6-SNAPSHOT, this
// fails with full whitespace too. The values from the Examples table are
// always preferred over the values specified in the step?
String patternAsString = "I live on the $ith floor but some call it the
$nth";
Method method = stepMethodFor("methodWithNamedParametersInNaturalOrder",
AnnotationNamedParameterSteps.class);
StepCandidate candidate = candidateWith(patternAsString, WHEN, method,
steps);
StepResult result =candidate.createMatchedStep("When I live on the first
floor but some call it the ground", namedParameters)
.perform(null);
// Will fail in 3.6-SNAPSHOT:
// java.lang.AssertionError: Expected: "first" got: "top"
assertThat(steps.ith, equalTo("first"));
// Will fail in 3.6-SNAPSHOT:
// java.lang.AssertionError: Expected: "ground" got: "penthouse"
assertThat(steps.nth, equalTo("ground"));
result.describeTo(reporter);
verify(reporter).successful(
"When I live on the " + PARAMETER_VALUE_START + "first" +
PARAMETER_VALUE_END + " floor but some call it the " + PARAMETER_VALUE_START +
"ground" + PARAMETER_VALUE_END );
}
{code}
In 3.5.4,
{{org.jbehave.core.parsers.RegexPrefixCapturingPatternParser#findParametersToReplace}}
finds {{ith,}} (including the comma) and {{nth}} as the parameter names. In
3.6 SNAPSHOT,
{{org.jbehave.core.parsers.RegexPrefixCapturingPatternParser.Parameter}} has
changed, and (correctly) finds {{ith}} and {{nth}}. But still the values from
the {{Examples:}} table overwrite both.
> 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
