Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Minor
-
Resolution: Not A Bug
-
Affects Version/s: 3.6.8
-
Fix Version/s: None
-
Component/s: Core
-
Labels:None
-
Environment:windows7, java 1.6.0-26
-
Number of attachments :
Description
I have a step method aliased like this (to be able to use the step with table parameters and explicitly as well)
@Then("title is \"$title\"")
@Alias("title is <title>")
public void thenTitleIs(@Named("title") final String title) {
logger.debug("thenTitleIsTable("+title+")");
}
when I now use the steps
... Then title is <title> ... Then title is "some other title"
the 2nd step gets the variable set from the first step
when the steps are defined in 2 different methods, the behavior is as expected.
Activity
example project
Alexander Lehmann
added a comment - example project Alexander Lehmann
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Attachment | jbehave-800.zip [ 60564 ] |
the report output is correct, however the string passed to the step method is always examplestring
Alexander Lehmann
added a comment - the report output is correct, however the string passed to the step method is always examplestring
Hi Alex,
what's the use case of wanting to execute both in the same scenario?
The parametrised scenario is designed to be executed as a whole using the parameters provided, e.g. by the examples table row.
Mauro Talevi
added a comment - Hi Alex,
what's the use case of wanting to execute both in the same scenario?
The parametrised scenario is designed to be executed as a whole using the parameters provided, e.g. by the examples table row.
I have a scenario that checks a few web pages where you have to be logged in, i.e. it logs in before and logs out afterwards, e.g. like this:
Given I am user "foo" When I log in Then title is "Welcome to service" When I go to <url> Then title is <title> When I log out Then title is "you have logged out" Examples: |url|title| |http://example.com/profile|Your profile| |http://example.com/stats|Your stats|
the steps Then title is <title> and Then title is "$title" have the same implementation, one with explicit parameter and one with example table parameter.
Alexander Lehmann
added a comment - I have a scenario that checks a few web pages where you have to be logged in, i.e. it logs in before and logs out afterwards, e.g. like this:
Given I am user "foo"
When I log in
Then title is "Welcome to service"
When I go to <url>
Then title is <title>
When I log out
Then title is "you have logged out"
Examples:
|url|title|
|http://example.com/profile|Your profile|
|http://example.com/stats|Your stats|
the steps Then title is <title> and Then title is "$title" have the same implementation, one with explicit parameter and one with example table parameter.
Hi Alex,
when you have a parametrised scenario, the named parameters in the examples tables values will override any value parsed from the step itself. In your case, you're using the same method to provide the title, from two sources. The problem is that we have no way of distinguishing for a given step when the source is the step and when the source is the table.
The workaround is to provide another annotated method as the hook for the either the named parameter or the parsed parameter. That's not necessarily a bad practice. Adding an annotated method that calls the previous one does not duplicate functionality, simply adds another DSL step definition.
At the moment, I can't think of a configurable way to distinguish between these two cases. Effectively, the parametrised scenario steps were designed to be thought as a self-contained unit and not mixed-n-match with parametrised steps.
If you can think of a better way, feel free to chip in ideas.
Mauro Talevi
added a comment - Hi Alex,
when you have a parametrised scenario, the named parameters in the examples tables values will override any value parsed from the step itself. In your case, you're using the same method to provide the title, from two sources. The problem is that we have no way of distinguishing for a given step when the source is the step and when the source is the table.
The workaround is to provide another annotated method as the hook for the either the named parameter or the parsed parameter. That's not necessarily a bad practice. Adding an annotated method that calls the previous one does not duplicate functionality, simply adds another DSL step definition.
At the moment, I can't think of a configurable way to distinguish between these two cases. Effectively, the parametrised scenario steps were designed to be thought as a self-contained unit and not mixed-n-match with parametrised steps.
If you can think of a better way, feel free to chip in ideas. thanks, i think it is simple enough to write two methods
Alexander Lehmann
added a comment - thanks, i think it is simple enough to write two methods
Alexander Lehmann
made changes -
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Not A Bug [ 6 ] |
This is not directly caused by the alias defintion, it doesn't work if a @Named parameter in a regular parameter has the same name as an example parameter.