[
http://jira.codehaus.org/browse/JBEHAVE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225888#action_225888
]
Paul Hammant commented on JBEHAVE-232:
--------------------------------------
I don't understand. I've been deeply involved in the @Named work and the
Paranamer integration (which negates the need for @Named for those who're comfy
with the informality it introduces), and don't follow what the issue is. Can
we have an attached testcase that fails when it should work ? Thanks.
> 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
