[jira] Updated: (JBEHAVE-145) Unit-test runners should decorate Exceptions a bit more clearly

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

Phil Wills updated JBEHAVE-145:
-------------------------------

    Attachment: step_in_exception.txt

> Unit-test runners should decorate Exceptions a bit more clearly 
> ----------------------------------------------------------------
>
>                 Key: JBEHAVE-145
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-145
>             Project: JBehave
>          Issue Type: Improvement
>    Affects Versions: 2.1
>            Reporter: Paul Hammant
>             Fix For: 2.2
>
>         Attachments: step_in_exception.txt
>
>
> Somewhere deep down in the runScenario logic, you could benefit from a try/catch(Throwable)/wrap-rethrow
> The wrapping exception could add textual information on the step that is failing.  Catch throwable
because you're not just catching AssertionErrors, you're catching Selenium timeouts.

--

-- 
This message is automatically generated by JIRA.
-

[jira] Commented: (JBEHAVE-145) Unit-test runners should decorate Exceptions a bit more clearly

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

Phil Wills commented on JBEHAVE-145:
------------------------------------

I'm attaching a patch which I think addresses to some extent what Paul is describing.  Ideally I think this
would be done with an ErrorStrategy, rather than a ScenarioReporter, but that doesn't seem achievable
with the interfaces as they stand.

> Unit-test runners should decorate Exceptions a bit more clearly 
> ----------------------------------------------------------------
>
>                 Key: JBEHAVE-145
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-145
>             Project: JBehave
>          Issue Type: Improvement
>    Affects Versions: 2.1
>            Reporter: Paul Hammant
>             Fix For: 2.2
>
>         Attachments: step_in_exception.txt
>
>
> Somewhere deep down in the runScenario logic, you could benefit from a try/catch(Throwable)/wrap-rethrow
> The wrapping exception could add textual information on the step that is failing.  Catch throwable
because you're not just catching AssertionErrors, you're catching Selenium timeouts.

Issues starting JBehave

Hi,

I am trying to develop with JBehave.  I am using Eclipse Classic
3.4.1, JDT 3.4, JBehave Version 2.1.

When I try to run the behavioral tests, it always says that "The
Source Not Found" ... "The source attachment does not contain the
source for the file JUnitScenario.class"

When I try to change the source it doesn't work.  I couldn't attach
the sample because it is too big but the library files i have attached
are ....
jbehave-core-2.1.1.jar
junit-4.4-src.jar
junit-dep-4.5.jar
jbehave-maven-plugin-2.1.jar
junit-4.5.jar

If someone could please reply me asap that would be great!  If I can't
get this working by the end of today I need to switch to a different
BDD language.

Thanks so much,

Laura

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

    http://xircles.codehaus.org/manage_email

[jira] Commented: (JBEHAVE-126) GivenScenarios

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

Elizabeth Keogh commented on JBEHAVE-126:
-----------------------------------------

GivenStory doesn't make any sense to me. I'm starting to think that Story, being another BDD domain term,
should be a completely separate object from Scenario (and the various types of Scenario). It might have
Scenarios as part of it. To run a GivenScenario, we might want to identify which Scenario in the Story is
being run.

Running all the Scenarios in a story to set up the context for anther Scenario makes no sense to me. Each
Scenario could well leave the application in a different state, so what context would you set up in the
Given? What state would you have, in which to perform the other steps?

No idea how Story as a separate object would work, but it feels like the right thing to do. Thoughts? 3.0 maybe?

> GivenScenarios
> --------------
>
>                 Key: JBEHAVE-126
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-126
>             Project: JBehave
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Elizabeth Keogh
>            Assignee: Mauro Talevi
>             Fix For: 2.2

[jira] Commented: (JBEHAVE-126) GivenScenarios

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

Mauro Talevi commented on JBEHAVE-126:
--------------------------------------

I agree that story should be a separate model concept.   The issue here is that we started with the Scenario
concept and then added the ability to run multiple scenarios, which in my mind constitutes a story.   So I
would only run a story (ie a set of scenarios) to set up a context for another story - that's why I was thinking
of calling it GivenStory.  I think this could be retrofitted in 2.x codebase, possibly.  Else we could
branch off a 3.x and revisit the whole model to be more story-aware.    

The alternative of keeping the GivenScenario as a context set up for each scenario is possible, but
complicates the parsing IMO in case you had multiple GivenScenario in a single file.  We need to evaluate
which of the two use cases is more used.  I'm thinking that most likely users would need a single setup call
for all the scenarios in their file.

> GivenScenarios
> --------------
>
>                 Key: JBEHAVE-126
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-126
>             Project: JBehave
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Elizabeth Keogh
>            Assignee: Mauro Talevi
>             Fix For: 2.2

Re: Issues starting JBehave

Laura Vendramini wrote:
> Hi,
> 
> I am trying to develop with JBehave.  I am using Eclipse Classic
> 3.4.1, JDT 3.4, JBehave Version 2.1.
> 
> When I try to run the behavioral tests, it always says that "The
> Source Not Found" ... "The source attachment does not contain the
> source for the file JUnitScenario.class"
> 
> When I try to change the source it doesn't work.  I couldn't attach
> the sample because it is too big but the library files i have attached
> are ....
> jbehave-core-2.1.1.jar
> junit-4.4-src.jar
> junit-dep-4.5.jar
> jbehave-maven-plugin-2.1.jar
> junit-4.5.jar
> 
> 
> If someone could please reply me asap that would be great!  If I can't
> get this working by the end of today I need to switch to a different
> BDD language.
> 
>

Hi Laura,

have you checked the FAQ regarding annotations in 
http://jbehave.org/documentation/faq/ ?

Re: Re: Issues starting JBehave

Thanks Mauro!  That worked

On Wed, Jan 14, 2009 at 9:42 AM, Mauro Talevi
<mauro.talevi@...> wrote:
> Laura Vendramini wrote:
>>
>> Hi,
>>
>> I am trying to develop with JBehave.  I am using Eclipse Classic
>> 3.4.1, JDT 3.4, JBehave Version 2.1.
>>
>> When I try to run the behavioral tests, it always says that "The
>> Source Not Found" ... "The source attachment does not contain the
>> source for the file JUnitScenario.class"
>>
>> When I try to change the source it doesn't work.  I couldn't attach
>> the sample because it is too big but the library files i have attached
>> are ....
>> jbehave-core-2.1.1.jar
>> junit-4.4-src.jar
>> junit-dep-4.5.jar
>> jbehave-maven-plugin-2.1.jar
>> junit-4.5.jar
>>
>>
>> If someone could please reply me asap that would be great!  If I can't
>> get this working by the end of today I need to switch to a different
>> BDD language.
>>
>>

Maven2 / JBehave issue running scenarios after a failure

Hi,
I have been using Maven2 and JBehave trying to work on a simple
example  calculator project. I tried to run through 3 scenarios.
Everything works fine if all the scenario results matches. However
when the results doesn't match, during test phase (mvn test) the
scenario runs until it reaches a scenario that fails and the process
stops. Say for example I have 3 scenarios, CalculatorSpecs,
MultiplyIntegersSpecs, SubtractIntegersSpecs, if MultiplyIntegersSpecs
fail it will give me a build error and stops without running
SubtractIntegersSpecs. I want to know how to make it run through all
of the scenarios and tell me which ones failed.

Note: I am trying to set up and pom.xml so that it works as I expect.
I am not using an IDE to run the behavioral tests. The multiply
scenario has been deliberately made so that it gives an error.

>>>>console error<<<<

[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jbehave:run-scenarios {execution: run-scenarios-found}]
[INFO] Running scenario CalculatorExample.spec.CalculatorSpecs
[INFO] Running scenario CalculatorExample.spec.MultiplyIntegersSpecs

Scenario: MultiplyIntegersSpec

Given I have two integers 5 and 2
When I want to multiply 5 and 2 together
Then the TOTAL should be 12 (FAILED)

Cucumber+JBehave=true

Re: Cucumber+JBehave=true

aslak hellesoy wrote:
> Hi gang,
> 
> With a little JRuby love I managed to hook Cucumber (http://cukes.info/) 
> up to JBehave. My latest commit:
> http://github.com/aslakhellesoy/cucumber/commit/855e033832e19b5ad248c57cfb4abc8f72fa2da0
> 
> What this means is that it will be possible to use Cucumber with Java, 
> implementing steps simply by subclassing
> org.jbehave.scenario.steps.Steps. I don't use the Scenario or runner 
> classes. The README in the link above
> explains why this is interesting.
> 
> I'm planning to package Cucumber in an executable cucumber.jar file so 
> people can run it from the command line,
> just like the pure ruby version.
> 
> Any thoughts on this?
> 
> Aslak (::)

Ehi Asklak,

welcome back to Java-land 

Very interesting stuff - I'll have a closer look and sniff at weekend. 
But looks promising ...

More later!

Cheers

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

    http://xircles.codehaus.org/manage_email