Hi Enrique,
The list of features can be found on JIRA:
http://jira.codehaus.org/browse/JBEHAVE/fixforversion/18486#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
Essentially, 4.x is meant to replace the execution engine of the stories
and its reporting, which will more flexible than 3.x and all
template-based.
I'll be "almost" backward compatible with 3.x - with few exceptions,
such as the CrossReference output.
One of my new year's resolution to get 4.0 out soon but no ETA as yet.
The betas of 4.x mirror closely the development of the 3.x main line.
As the 4.x is meant to be functionally equivalent we want to ensure they
are properly tested.
You should try them out. As usual all feedback is most welcome.
Cheers
On 20/01/2014 22:35, Jorge Pombar wrote:
Mauro,
I've been hearing of really great improvement for 4.0 for a while. Do you have
a feature list for 4.0? Also do you have an ETA of a non Beta release?
Thanks,
Enrique
-----Original Message-----
From: Mauro Talevi [mailto:[email protected]]
Sent: Sunday, January 19, 2014 8:42 AM
To: [email protected]
Subject: Re: [jbehave-user] Differentiating between test failures and test
errors
I would not really go down that route.
In 4.x StoryRunner will be completely replaced by a different tree-based
execution engine called PerformableTree. The idea is to create a tree
of performable objects that can contain runtime results which can then be
rendered in a template, thereby rendering the story reporter obsolete.
I'd prefer you gave the latest 4.0-beta-4 a whirl (I've released it today and
it should be synched soon to Maven Central).
You could start by creating a new JIRA issue outlining your use case and we
take it from there.
On 19/01/2014 12:05, Stephen de Vries wrote:
Thank Mauro,
Ideally, I'd like to see the error in the xml and html files, e.g. <step
outcome="error"> , so it sounds like I'd have to re-implement StoryRunner and
create a custom StoryReporter to achieve this? Is there an easier way?
On 19 Jan 2014, at 11:21, Mauro Talevi <[email protected]> wrote:
JBehave supports the definition of a custom and configurable FailureStrategy,
which defaults to RethrowingFailure.
You can provide your own implementation which can check if the Throwable is an
UnexpectedContentException or not and decide how to handle it, e.g. log a
message and swallow the exception.
Be aware though that if you do rethrow the exception, it'll be treated by the
JBehave story execution as a failure. So there is no specific mechanism to
distinguish the failures thereafter.
On 19/01/2014 09:54, Stephen de Vries wrote:
Hi,
Is there a mechanism in JBehave to differentiate between a scenario failure and
a scenario error? Basically, when a scenario fails I'd like to know whether
it's a problem with my test, or a problem with the application under test.
I'm using JBehave for security tests, so a scenario failure indicates a security
vulnerability; but I have error checking logic in the test itself which just ensures that
the test is behaving properly, so if there's an error in the test then I don't want the
test to "fail" but rather to throw some kind of distinguishable error
condition, like in the following contrived example:
@Then("bob must not see alice's private data") public void
checkAccessControl() {
loginAsBob();
driver.get(bobsPage);
if (notOnBobsPage()) throw UnexpectedContentException("Can't access bob's
page even though bob is logged in"); //Test error
driver.get(alicesPage);
assertThat("bob can see alices data", canViewAlicesData(),
is(true)); //Application error and security vulnerability }
In the case above, I'd like the scenario outcome to be different if
assertion fails vs if the UnexpectedContentException is thrown. If there's no
native way to do this in JBehave, do you have any ideas on the easiest way to
achieve this?
regards,
Stephen
--------------------------------------------------------------------
- To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
