Details
-
Type:
Improvement
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.2
-
Fix Version/s: 2.5
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
We have run into some difficulty declaring steps that have similar wording such that the matching was incorrect for some of our scenarios. For example:
We have a line from one of scenarios that looks like this:
And the table.testtable with test_1_id of foo has exactly one test_2_id of bar
We want this line to match on the following step:
@Given("the $tableName with $whereColumnName of $whereColumnValue has exactly one $selectColumnName of $selectColumnValue")
But instead the match is always occuring on this step:
@Given("the $tableName with $whereColumnName of $whereColumnValue has $selectColumnName of $selectColumnValue")
where $selectColumnName gets interpreted as "exactly one test_2_id"
Can we have an annotation that indicates the order by which the matching occurs? That way, the first step in our example would always get compared first to our example input line instead of step two. For example something like this:
@Order(1)
@Given("the $tableName with $whereColumnName of $whereColumnValue has exactly one $selectColumnName of $selectColumnValue")
@Order(2)
@Given("the $tableName with $whereColumnName of $whereColumnValue has $selectColumnName of $selectColumnValue")
Activity
Mauro Talevi
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 2.3 [ 14941 ] | |
| Fix Version/s | 2.2 [ 14670 ] |
In the end, this is what we did. But this then forces you to change your language to get around this issue. In my opinion, the code should be flexible enough to recognize the difference between two different steps. The @Order (or whatever you want to call that) would do this. There might be a cleaner way to do this, but this was the first thing that came to mind.
Douglas Padian
added a comment - In the end, this is what we did. But this then forces you to change your language to get around this issue. In my opinion, the code should be flexible enough to recognize the difference between two different steps. The @Order (or whatever you want to call that) would do this. There might be a cleaner way to do this, but this was the first thing that came to mind. Mauro Talevi
made changes -
| Fix Version/s | 2.3 [ 14941 ] | |
| Fix Version/s | 2.4 [ 15664 ] |
Would changing the match to use non-greedy match not help?
Current implementation is greedy:
this.anyWordBeginningWithThePrefix = "(
" + prefix + "\\w*)(\\W|
Z)";
changing it to:
this.anyWordBeginningWithThePrefix = "(
" + prefix + "\\w*?)(\\W|
Z)"; //notice the ?
will make the matching stop at the first whitespace instead of the last possible.
Hitesh
added a comment - Would changing the match to use non-greedy match not help?
Current implementation is greedy:
this.anyWordBeginningWithThePrefix = "( " + prefix + "\\w*)(\\W| Z)";
changing it to:
this.anyWordBeginningWithThePrefix = "( " + prefix + "\\w*?)(\\W| Z)"; //notice the ?
will make the matching stop at the first whitespace instead of the last possible. I think that might work – please run your proposed solution against the example that I posted and see if it works properly. If it does, that is a more elegant solution.
Douglas Padian
added a comment - I think that might work – please run your proposed solution against the example that I posted and see if it works properly. If it does, that is a more elegant solution. Added order_matching.scenario in trader example to reproduce simplified behaviour and allow investigation.
The non-greedy regex solution did not seem to work.
Mauro Talevi
added a comment - Added order_matching.scenario in trader example to reproduce simplified behaviour and allow investigation.
The non-greedy regex solution did not seem to work. More investigation is needed, so descoping it from 2.4 release.
Mauro Talevi
added a comment - More investigation is needed, so descoping it from 2.4 release.
Mauro Talevi
made changes -
| Fix Version/s | 2.5 [ 15850 ] | |
| Fix Version/s | 2.4 [ 15664 ] |
Reclassified from bug to enhancement.
Mauro Talevi
added a comment - Reclassified from bug to enhancement. Mauro Talevi
made changes -
| Issue Type | Bug [ 1 ] | Improvement [ 4 ] |
Mauro Talevi
made changes -
| Assignee | Mauro Talevi [ maurotalevi ] |
Added optional priority attribute to step method annotations (@Given, @When, @Then), to allow ordering or priotisation of methods whose regex patterns both match the same text step. To prioritise the less-greedy pattern, simply give it a higher priority (which by default is zero):
@Given(value = "the $tableName with $whereColumnName of $whereColumnValue has exactly one $selectColumnName of $selectColumnValue", priority=1)
will take precendence over
@Given("the $tableName with $whereColumnName of $whereColumnValue has $selectColumnName of $selectColumnValue")
Mauro Talevi
added a comment - Added optional priority attribute to step method annotations (@Given, @When, @Then), to allow ordering or priotisation of methods whose regex patterns both match the same text step. To prioritise the less-greedy pattern, simply give it a higher priority (which by default is zero):
@Given(value = "the $tableName with $whereColumnName of $whereColumnValue has exactly one $selectColumnName of $selectColumnValue", priority=1)
will take precendence over
@Given("the $tableName with $whereColumnName of $whereColumnValue has $selectColumnName of $selectColumnValue")
Mauro Talevi
made changes -
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
I'm not sure that we'd gain much by adding an @Order annotation.
Couldn't you just add a qualifier in the second Given step: e.g. adding "at least one" to match the "exactly one" of the other step, and thus distinguishing the two steps?