Details
Description
I've attached a stripped-down example to demonstrate the problem. Notice that in the failure case the parameter in the table is lower-cased causing it to mis-match the parameter in the scenario which is camel-cased.
My original email for context:
One of the testers accidentally checked-in a partial change list, causing JBehave to throw RunningStoriesFailedException and StoryResourceNotFound exceptions. In and of itself, this isn't a big deal. However, we are calling webDriver.close() in @AfterStory (this closes the browser window). In the case of a RuntimeException, I doesn't look like @AfterStory is called, which leaves the browser running. Since our tests need to share a profile (and only one instance of the profile may be run at a time), this causes future tests to hang until the browser is closed manually. In a Continuous Integration environment, this is non-trivial.
My Question:
In the case that JBehave throws a RuntimeException, is there a way to trap it so that we can close down the browser?
Mauro's Response:
OTOH all exceptions (in fact throwables) should be caught. Could you
create a sample project reproducing problem and attached it a jira issue?
Please try against latest 3.0-beta-12 which has just been cut.
Activity
Field | Original Value | New Value |
---|---|---|
Summary | @AfterStory method is not invoked in the case that a RuntimeException is thrown | @AfterStory method is not invoked is step parametrisation fails |
Resolution | Fixed [ 1 ] | |
Status | Open [ 1 ] | Resolved [ 5 ] |
Failures in step parametrisation are now caught and appropriate step results returned.