I've been working on an Arquillian-Jbehave extension to enable BDD tests to run in-container, and it's more or less ready for an Alpha1 release. But before that, I'd like some feedback on a few areas of concern:
Extraction of Resources required for JBehave reports
Currently, I have an Observer (ViewResourcesUnpacker) that unpacks resource artifacts hosted at Maven Central, into the 'target/jbehave/view' directory. This more or less performs the same task as the UnpackViewResources mojo of the jbehave-maven plugin. The observer was written to prevent the apperance that the extension is "broken" (since the reports would be displayed without the stylesheets and other resources), and also to do away with documentation on the need to run the jbehave-maven-plugin:unpack-view-resource goal. However, after accounting for CI servers, and Arquillian users that use Ant/Ivy/Gradle etc., I'm reconsidering this decision. What do you think?
Dependency injection of Steps instances is performed by the ArquillianInstanceStepsFactory, using TestEnrichers that have been stored in a ThreadLocal property of the StepEnricherProvider class. This contraption is kind of necessary given that Arquillian performs injection into Test instances, and not Step instances. To add to the complexity, JBehave creates new Threads using an ExecutorService, to run the Scenarios and associated Steps; note that JBehave drives the ArquillianInstanceStepsFactory to create the necessary Steps for a scenario so any dependency injection performed by this StepsFactory occurs in the same thread and context as the one created by JBehave. It is possible to configure the ExecutorService used by JBehave, and the examples demonstrate this (see the constructor), by using the Guava SameThreadExecutor to retain the original Arquillian contexts in the same thread as used by JBehave.
It is quite apparent that we need to package and use Guava (or any other library that provides a similar ExecutorService that doesn't spawn off new threads). Therefore, my questions are - Is there any such "lightweight" replacement for Guava? And should we roll out our own ExecutorService that does something similar?
Also, should we decide on an ExecutorService for the users of this extension (by creating a class ArquillianJUnitStory) ? Or, do we allow users to configure it like in the example?
LifeCycle of Drone injected WebDriver/Selenium instances
I've plans to "borrow" the concepts supported by PerStoryWebDriverSteps/PerStoriesWebDriverSteps/PerScenarioWebDriverSteps classes of JBehave-Web, to allow for WebDriver/Selenium instances to be valid for a certain scope (like a single step, multiple steps, single scenario, or multple scenarios), instead of the entire test execution. This may not appear in the Alpha1 release.
PS: In case you'd like to read the notes, they're here in a Gist.