When aliasing a step method with table parameter and without, the parameter is not correctly processed if both are used in the same scenario

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.

example project

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.

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.

thanks, i think it is simple enough to write two methods