@AfterStory method is not invoked is step parametrisation fails
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.
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.