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
