headers
Mauro Talevi | 9 Mar 2010 20:36

JBehave 2.5 released

The team is happy to announce the release of JBehave 2.5.

Announcement: http://jbehave.org/2010/03/09/jbehave-2-5-released/

Release note:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10680&version=15850

Download: http://jbehave.org/download

Reference: http://jbehave.org/reference/stable

Cheers

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 0 comments |
headers
Stephen Cresswell (JIRA | 12 Mar 2010 11:04

[jira] Created: (JBEHAVE-244) Step parameters should be converted just before the step executes (not when the scenario is parsed)

Step parameters should be converted just before the step executes (not when the scenario is parsed)
---------------------------------------------------------------------------------------------------

                 Key: JBEHAVE-244
                 URL: http://jira.codehaus.org/browse/JBEHAVE-244
             Project: JBehave
          Issue Type: Improvement
          Components: Core
    Affects Versions: 2.5
            Reporter: Stephen Cresswell
             Fix For: 2.6
         Attachments: BaseSteps.groovy, LazyCandidateStep.groovy

I should be able to use a ParamaterConverter to retrieve an entity from the database, e.g.

Given an employee called Bob
When I give Bob a pay rise of 10,000 pounds
Then Bob forgets about his embarrassing law suit

{code:title=EmployeeSteps.java|borderStyle=solid}
 <at> Given("an employee called $name")
public void createEmployee(String name) {
   new EmployeeBuilder().name(name).buildAndSave();
}

 <at> When("I give $employee a pay rise of $amount pounds")
public void givePayRise(Employee employee, Integer amount) {
   employee.increaseSalary(amount);
}
{code}
(Continue reading)

Permalink | Reply | 4 comments |
headers
Mauro Talevi (JIRA | 13 Mar 2010 21:16

[jira] Created: (JBEHAVE-245) Abstract scenarios should not be executed

Abstract scenarios should not be executed
-----------------------------------------

                 Key: JBEHAVE-245
                 URL: http://jira.codehaus.org/browse/JBEHAVE-245
             Project: JBehave
          Issue Type: Improvement
          Components: Ant extension, Maven Plugin
            Reporter: Mauro Talevi
            Assignee: Mauro Talevi
            Priority: Minor
             Fix For: 2.5.1

Automatically exclude scenario classes that are abstract.

--

-- 
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
Permalink | Reply | 1 comment |
headers
Mauro Talevi (JIRA | 13 Mar 2010 21:18

[jira] Resolved: (JBEHAVE-245) Abstract scenarios should not be executed


     [
http://jira.codehaus.org/browse/JBEHAVE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mauro Talevi resolved JBEHAVE-245.
----------------------------------

    Resolution: Fixed

> Abstract scenarios should not be executed
> -----------------------------------------
>
>                 Key: JBEHAVE-245
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-245
>             Project: JBehave
>          Issue Type: Improvement
>          Components: Ant extension, Maven Plugin
>            Reporter: Mauro Talevi
>            Assignee: Mauro Talevi
>            Priority: Minor
>             Fix For: 2.5.1
>
>
> Automatically exclude scenario classes that are abstract.

--

-- 
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
-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Cresswell (JIRA | 15 Mar 2010 23:13

[jira] Updated: (JBEHAVE-244) Step parameters should be converted just before the step executes (not when the scenario is parsed)


     [
http://jira.codehaus.org/browse/JBEHAVE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stephen Cresswell updated JBEHAVE-244:
--------------------------------------

    Attachment: Added_support_for_deferred_parameter_conversion.patch

Please find attached a patch containing test cases and one possible solution. If you decide it's worth
incorporating I think the attached would benefit from extracting the ParameterConverter interface and
anonymous Steps class into their own files.

Another solution would to be always defer parameter conversion, but there's  chance this would create
problems if someone, somewhere relied on the conversion occurring before the scenario had run.

> Step parameters should be converted just before the step executes (not when the scenario is parsed)
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBEHAVE-244
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-244
>             Project: JBehave
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 2.5
>            Reporter: Stephen Cresswell
>             Fix For: 2.6
>
>         Attachments: Added_support_for_deferred_parameter_conversion.patch, BaseSteps.groovy, LazyCandidateStep.groovy
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Ravn (JIRA | 17 Mar 2010 17:22

[jira] Created: (JBEHAVE-246) Improve terminology, the distinction between a story and a scenario

Improve terminology, the distinction between a story and a scenario
-------------------------------------------------------------------

                 Key: JBEHAVE-246
                 URL: http://jira.codehaus.org/browse/JBEHAVE-246
             Project: JBehave
          Issue Type: Improvement
            Reporter: James Ravn

I think it's unfortunate that a scenario file contains several other scenarios. This leads to some
ambiguities in the system, such as the meaning of a {{GivenScenario}}, and also in communication (is a
scenario a collection or a scenario?).

It also is somewhat a violation of the literal meaning of scenario - which by definition contains other
stories or scenes, not scenarios.

I think while the framework is still relatively young it would be worth addressing this design choice.
Perhaps a scenario should contain stories, or something like that.

The main concern is removing the ambiguity about what a scenario is.

--

-- 
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:
(Continue reading)

Permalink | Reply | 5 comments |
headers
Stephen Cresswell (JIRA | 17 Mar 2010 22:48

[jira] Created: (JBEHAVE-247) jBehave should be more intelligent/flexible with regards to priortisation of steps

jBehave should be more intelligent/flexible with regards to priortisation of steps
----------------------------------------------------------------------------------

                 Key: JBEHAVE-247
                 URL: http://jira.codehaus.org/browse/JBEHAVE-247
             Project: JBehave
          Issue Type: Improvement
            Reporter: Stephen Cresswell
            Priority: Minor
         Attachments: LevenshteinDistance.java, PrioritizableUnmatchedToPendingStepCreator.java

BDD's strength relies on being able to write fluent scenarios. jBehave's support for this is very good, but
there is still room for improvement. For example a typical scenario might read...

{quote}
Scenario: Schedule Patient Discharge

Given a medical patient called Bob Holness who is not medically fit
When I change Bob's state to medically fit
And select a discharge time of tomorrow morning
And select a discharge complexity of 3 
{color:red}Then Bob's discharge schedule should be displayed on the ward board{color}
{quote}

Now in a related scenario let's say I want to cancel while rescheduling a discharge...

Scenario: Cancel Rescheduling Patient Discharge

{quote}
Given a medical patient called Bob Holness who already has a discharge schedule
(Continue reading)

Permalink | Reply | 5 comments |
headers
Paul Hammant (JIRA | 17 Mar 2010 23:45

[jira] Commented: (JBEHAVE-247) jBehave should be more intelligent/flexible with regards to priortisation of steps


    [
http://jira.codehaus.org/browse/JBEHAVE-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=214279#action_214279
] 

Paul Hammant commented on JBEHAVE-247:
--------------------------------------

Interesting.  I've not looked at the patch.  There is a prioritization scheme already (plain numeric
attached to the annotation), but that's not why I'm commenting.

Thinking about the language of what you're doing, and concentrating on the Given lines only :-

   Given a medical patient called Bob Holness who is not medically fit
      vs
   Given a medical patient called Bob Holness who already has a discharge schedule

What it "who" were a synonym for And here?
Such that, in terms of fitting the current JBehave, the Givens could be re-written as 

   Given a medical patient called Bob Holness 
   And is not medically fit
      vs
   Given a medical patient called Bob Holness 
   And already has a discharge schedule

Obviously that's more Inglish than English, but it could point to an enhancement where subtle 'And' breaks
could be recognized at subjective or objective case pronouns*.  Subject to configuration of course.

* http://owl.english.purdue.edu/owl/resource/595/02/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Cresswell (JIRA | 18 Mar 2010 10:37

[jira] Commented: (JBEHAVE-247) jBehave should be more intelligent/flexible with regards to priortisation of steps


    [
http://jira.codehaus.org/browse/JBEHAVE-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=214324#action_214324
] 

Stephen Cresswell commented on JBEHAVE-247:
-------------------------------------------

Hi Paul,

Using Who and And interchangeably on a per step cases would work well. The Given steps I used as examples are
some of our more simplistic, there are lots more variations...

"a $gender, $speciality patient called $name, in "$location" who is $state
e.g. Given a male, cardiovascular patient called Bob Holness, in "Bed 05, Ward 1", who is not medically fit

Being able to split these up into smaller steps would make the scenarios more readable and reduce the number
of complex steps....

{quote}Given a male patient called Bob Holness // we should probably auto assign gender based on known names
{color:red}with{color} a cardiovascular speciality
{color:red}located{color} in Bed 05, Ward 1
{color:red}who{color} is not medically fit{quote}

"but" would be a useful synonym too

{quote}Then Bob's bed changes to Bed 6
{color:red}but{color} his* admission date stays as 15/07/74{quote}

\*our PatientParameterConverter is smart enough to recognise "his/her" and use the "current" patient
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Ron (JIRA | 19 Mar 2010 21:16

[jira] Created: (JBEHAVE-248) Should be able to use Jbehave without inheriting from a base class

Should be able to use Jbehave without inheriting from a base class
------------------------------------------------------------------

                 Key: JBEHAVE-248
                 URL: http://jira.codehaus.org/browse/JBEHAVE-248
             Project: JBehave
          Issue Type: New Feature
          Components: Core
         Environment: Any
            Reporter: David Ron

Currently, a JBehave test scenario require inheriting from the base Scenario class.  Certain other test
frameworks may also require inheritance, but multiple inheritance is not allowed in Java.  For this
reason, configuration of a delegate Scenario may be preferred.  I created a blog entry with the necessary
code to accomplish this:
http://blog.davidron.com/2009/12/breaking-jbehave-inheritance-hierarchy.html

--

-- 
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
(Continue reading)

Permalink | Reply | 7 comments |

Gmane