jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • JBehave
  • JBEHAVE-216

Allow to indicate which is the weight of each StepsCandidate class used by a Scenario class to resolve duplicated methods.

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: New Feature New Feature
  • Status: Reopened Reopened
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.4
  • Fix Version/s: None
  • Component/s: Core
  • Labels:
    None

Description

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.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Jonathan Ross added a comment - 14/Jan/10 1:39 PM

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.

Show
Jonathan Ross added a comment - 14/Jan/10 1:39 PM 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.
Hide
Permalink
Mauro Talevi added a comment - 21/Feb/10 4:22 PM

A solution is now provided by the ability to prioritise step methods (see JBEHAVE-162).

All candidate steps, coming from all Steps classes, are collected and prioritised.

Show
Mauro Talevi added a comment - 21/Feb/10 4:22 PM A solution is now provided by the ability to prioritise step methods (see JBEHAVE-162). All candidate steps, coming from all Steps classes, are collected and prioritised.
Hide
Permalink
Mauro Talevi added a comment - 21/Feb/10 4:38 PM

Not providing prioritisation of Steps classes as we now have the prioritisation of constituent Steps methods (see JBEHAVE-162). Should it prove necessary, we'll review and re-address issue at later stage.

Show
Mauro Talevi added a comment - 21/Feb/10 4:38 PM Not providing prioritisation of Steps classes as we now have the prioritisation of constituent Steps methods (see JBEHAVE-162). Should it prove necessary, we'll review and re-address issue at later stage.
Hide
Permalink
Mauro Talevi added a comment - 26/Feb/10 1:53 AM

Rather than resolving it as Won't Fix, re-opening and descoping this features in case it does turn out to be needed.

Show
Mauro Talevi added a comment - 26/Feb/10 1:53 AM Rather than resolving it as Won't Fix, re-opening and descoping this features in case it does turn out to be needed.

People

  • Assignee:
    Unassigned
    Reporter:
    Cristiano Gavião
Vote (0)
Watch (1)

Dates

  • Created:
    07/Dec/09 3:49 PM
    Updated:
    26/Feb/10 1:53 AM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.