[jbehave-dev] [jira] Commented: (JBEHAVE-163) Support comments in plain-text scenarios
[ http://jira.codehaus.org/browse/JBEHAVE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206973#action_206973 ] Jonathan Ross commented on JBEHAVE-163: --- Unfortunately, if the step preceding the comment ends with a variable, the pattern matcher gets greedy... I would also like to be able to use comments between steps, and the only work-around I have currently is to avoid ending a step annotation with a variable - this doesn't always lead to natural prose! Some solutions I can come up with: 1. add a commas or period followed by a new line to the syntax as step delimiters, e.g. Given a comma or period after a $variable, i can put a comment here without it being swallowed by the pattern matcher, And i can proceed with the scenario. 2. provide regexp support in the step annotations, e.g.: @Before(Given a step matching a variable at the end, like so: $([^\n]*)) 3. provide another mechanism for distinguishing between single and multi-line variables 4. add comment prefixes as suggested by the original post Support comments in plain-text scenarios Key: JBEHAVE-163 URL: http://jira.codehaus.org/browse/JBEHAVE-163 Project: JBehave Issue Type: New Feature Affects Versions: 2.2 Reporter: Douglas Padian Priority: Minor Fix For: 2.5 It would be nice to have the ability to add comments in the plain-test scenarios. If we add any comments, the parser thinks they are the continuation of the previous line. To have comment support so that all lines preceded by # or -- or whatever get ignored, that would be a nice feature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.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
[jbehave-dev] [jira] Commented: (JBEHAVE-216) Allow to indicate which is the weight of each StepsCandidate class used by a Scenario class to resolve duplicated methods.
[ http://jira.codehaus.org/browse/JBEHAVE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206974#action_206974 ] Jonathan Ross commented on JBEHAVE-216: --- A similar issue comes into play if you have similarly worded steps, like @When(the user logs in as $user) @When(the user logs in as $user, with password $password) If the second step is listed first in the Steps class, it will match When the user logs in as me, with password xxx correctly, but if it is second in the file, the first step will be executed with me, with password xxx as the user variable. Usually it is more natural to declare steps (java methods in general) in ascending order of complexity. Perhaps this should be a separate jira ticket, but this could be solved by using non-greedy matching, or, as a bit of a hack, by sorting the annotations in descending string length. Allow to indicate which is the weight of each StepsCandidate class used by a Scenario class to resolve duplicated methods. -- Key: JBEHAVE-216 URL: http://jira.codehaus.org/browse/JBEHAVE-216 Project: JBehave Issue Type: New Feature Components: Core Affects Versions: 2.4 Reporter: Cristiano Gavião Fix For: 2.5 With the addition of the GivenScenarios feature, almost often will be necessary to inform more than one StepsCandidate class for one Scenario class. The problem is that those StepsCandidates could have same methods, or could be extending the same parent class and sharing same method. Jbehave will get the first occurrence of method that match textual sentence, which not necessarily will be the desired one. So I would like that jbehave had some way to stablish a weight, or an order, or maybe indicate a default steps class (or anything like that) where I could indicate which is the best path it should be taken. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.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
[jbehave-dev] [jira] Created: (JBEHAVE-232) Replace @Named variable annotation by pattern matching of variable names used in step annotation
Replace @Named variable annotation by pattern matching of variable names used
in step annotation
Key: JBEHAVE-232
URL: http://jira.codehaus.org/browse/JBEHAVE-232
Project: JBehave
Issue Type: Improvement
Components: Core
Affects Versions: 2.3.2
Reporter: Jonathan Ross
If the {...@named}} annotation was deprecated, and the {{$variable}} patterns
were matched to the steps argument list instead, jBehave would be much more
usable.
The {...@named}} parameter annotations are in essence redundant, and they limit
usability of jBehave for two reasons:
1. _The parameter names could be parsed directly from the step scenario
instead_. And I wish they were: I (and my testers) have frequently run into
the problem of the arguments being in the wrong order. An innocent looking
step like
{code}
@Given(a book $book written by $author)
@Alias($author's book $book)
public void setBookAndAuthor(@Named(author) String author, @Named(book)
String book) {...}
{code}
can lead to great confusion, with the arguments getting switched. Using the
step in an example scenario can increase the confusion, as one can legally
write:
{code}
Given a book [author] written by [book]
{code}
Testers and developers alike are also confused that, while {{Given a book Moby
Dick written by Herman Melville}} works, {{Given [title] written by [person]}}
doesn't (see next point).
2. _they inhibit reusing steps in example scenarios_; either that, or they lead
to redundant columns.
An example to illustrate this: given
{code}
@Given(a stock named $stock)
public void createStock(@Named(stock) String stock)...
{code}
I cannot reuse this step for two colums in an example:
{code}
Scenario: client creates two stocks
Given a stock named [A]
And a stock named [B]
Examples:
|A |B |
|GOOG | AAPL |
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.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
[jbehave-dev] [jira] Created: (JBEHAVE-233) Eclipse plugin for navigating between textual and code steps
Eclipse plugin for navigating between textual and code steps Key: JBEHAVE-233 URL: http://jira.codehaus.org/browse/JBEHAVE-233 Project: JBehave Issue Type: New Feature Reporter: Jonathan Ross As an avid user of jBehave, I find maintaining steps very laborious, so I would like an eclipse plugin with: * support for opening declarations of steps from the scenario files * support for finding usages of steps in scenario files from the declaration * support for opening the declaration of failed steps when running junit Nice to have: * refactoring support: when editing the annotations, scenarios using the step get rewritten -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.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
[jbehave-dev] [jira] Created: (JBEHAVE-234) Improve JUnit integration
Improve JUnit integration - Key: JBEHAVE-234 URL: http://jira.codehaus.org/browse/JBEHAVE-234 Project: JBehave Issue Type: Improvement Reporter: Jonathan Ross As a developer using jBehave running in JUnit in Eclipse, I would like to easily determine 1. how many individual scenarios have passed or failed, and 2. which steps failures occur in What springs to mind, is to wire each scenario up as separate JUnit TestCase (rather than the single 'testScenario()' method). Doing so, I would easily be able to drill down to the individually failing scenarios more easily. Regarding finding out which step failed, short of writing a fully-fledged plug-in, this would be a simple matter of retaining the actual failure exception and setting this in JUnit's test result - the failed step should be in the stack trace reported by JUnit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.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
