Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: 3.7.5
-
Fix Version/s: None
-
Component/s: Core
-
Environment:$ java -version
java version "1.7.0_09"
OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-0ubuntu1~12.10.1)
OpenJDK Server VM (build 23.2-b09, mixed mode)
-
Number of attachments :
Description
When values from example table are populated into scenario they are shown in different color. The problem is that if a step contains a word equal to a value from the table it's also shown in that color which might be confusing (see screenshot attached).
To reproduce this I just modified the claims_with_null_calendar.story from trader examples as shown on the screenshot.
Activity
In background I'm working on the fix for this bug and I think I almost made it.
The problem is that StepCreator.markParsedParameterValue looks in the string from a story file and "marks" all words equal to the value. To fix that we can just implement more rigorous checks there.
Volodymyr Sobotovych
added a comment - In background I'm working on the fix for this bug and I think I almost made it.
The problem is that StepCreator.markParsedParameterValue looks in the string from a story file and "marks" all words equal to the value. To fix that we can just implement more rigorous checks there. What kind of checks are you thinking of? Starting from the texual step, how would you do it?
Ideas most welcome 
Mauro Talevi
added a comment - What kind of checks are you thinking of? Starting from the texual step, how would you do it?
Ideas most welcome
I'm thinking of using RegexStepMatcher to "mark" the parameters as it knows the structure of the step. For that matter I introduced the new interface method StepMatcher.markParameters and implemented it for RegexStepMatcher. You can find the sketch implementation in my private branch: https://github.com/wheleph/jbehave-core/commit/ebf77903883f5fdf4b9c0e441455ddd1eec3e71c
I think that introducing of the new interface method is OK because StepMatcher is not directly used in Configuration and hence there's a very tiny chance that it has been customized by someone whose code could be broken by that new method that should be implemented.
I think that we could also push marking of "examples" parameters (for ex. "Given Airline <air_code> is valid").
What do you think about that?
Volodymyr Sobotovych
added a comment - I'm thinking of using RegexStepMatcher to "mark" the parameters as it knows the structure of the step. For that matter I introduced the new interface method StepMatcher.markParameters and implemented it for RegexStepMatcher. You can find the sketch implementation in my private branch: https://github.com/wheleph/jbehave-core/commit/ebf77903883f5fdf4b9c0e441455ddd1eec3e71c
I think that introducing of the new interface method is OK because StepMatcher is not directly used in Configuration and hence there's a very tiny chance that it has been customized by someone whose code could be broken by that new method that should be implemented.
I think that we could also push marking of "examples" parameters (for ex. "Given Airline <air_code> is valid").
What do you think about that? It's an interesting proposal. No problems in delegating responsibility to the StepMatcher or adding new methods, but it introduces two regressions:
Failed tests:
shouldCreatePerformableStepWithResultThatDescribesTheStepPerformed(org.jbehave.core.steps.StepCandidateBehaviour):
shouldCreateParametrisedStepWithParsedParametersValues(org.jbehave.core.steps.StepCreatorBehaviour):
Can you please investigate why?
Also, please prefix your commit messages with "JBEHAVE-876: ".
Mauro Talevi
added a comment - It's an interesting proposal. No problems in delegating responsibility to the StepMatcher or adding new methods, but it introduces two regressions:
Failed tests:
shouldCreatePerformableStepWithResultThatDescribesTheStepPerformed(org.jbehave.core.steps.StepCandidateBehaviour):
shouldCreateParametrisedStepWithParsedParametersValues(org.jbehave.core.steps.StepCreatorBehaviour):
Can you please investigate why?
Also, please prefix your commit messages with " JBEHAVE-876 : ". 
This apparently happens since marking the values happens after the string is replaced and not before.
Not sure how to fix this, it is already in the string passed to the reporter.