Proposed Features for the Arquillian-JBehave Integration
Features for the Arquillian-JBehave integration
Other facts to consider
- Feature: Execution of stories in-container (obviously)
- Note - This works as intended, now.
- Feature: Execution of stories at the client (again, obviously)
- Note - This works as intended, now.
- Feature: Injection of dependencies into the JBehave Steps classes. It would be worth looking at reusing the
TestEnrichers used by Arquillian to originally enrich the test class.
Dependency injection might be possible if the integration were to provide a custom
InjectableStepsFactory that injects the step instances with the required dependencies.
- Note - This is now currently possible. All looks good, except for the manner in which it has been achieved. JBehave executes stories in a new thread. This results in the unavailability of the contexts and
ThreadLocal datastores used by the
TestEnrichers. The hack/workaround for this is to first obtain references to the enrichers by
Before event. Once references to these enrichers are obtained, dependency injection is performed on the Step instances before the threads are spawned, so that the injected fields are available during execution of stories. This is probably not a good idea for handling lazy injection of
- Note - We might want to investigate building a Arquillian-JBehave bridge that makes the contexts and other
ThreadLocal objects in the Arquillian thread available to the JBehave thread (how?).
- Note - JBehave allows for configuration of the
ExecutorService used to execute the stories. We could configure this to obtain the
com.google.common.util.concurrent.MoreExecutors.SameThreadExecutorService that does not spawn a new thread. However, we must avoid this if we want users to run stories concurrently.
- Feature: Injection of WebDriver/Selenium instances using Arquillian Drone, into tests and steps running at the client. This would make it possible for JBehave-Core to be used in isolation with Arquillian, without depending on JBehave-Web thus allowing for easier dependency management; a developer/user can pull in all dependencies from the Arquillian project.
- Note - This is now possible, via the same concepts used for using
TestEnrichers to enrich the Steps instances. There is one minor problem - the
DroneContext is enabled by
DroneConfigurator only when a
@Drone annotated field is declared in the test class, and this 'hack' must be used in the interim.
- Feature: Injection of
@ArquillianResource annotated dependencies, into tests and steps running at the client.
- Note - This is now possible, via the
- Feature: Support for annotated configuration like
- Note - Better to defer these, as they're used by
AnnotatedPathRunner types, which have to be extended for Arquillian. While it is possible to extend these classes, the extended classes must also incorporate the behavior of the
Arquillian JUnit4 test runner.
- Feature: Creation of JBehave reports for in-container executed stories, in a suitable location. Currently, the reports are
generated in a filesystem path relative to the deployed stories in a container; if the container is in a remote machine, the reports would be generated on the remote file system, reducing their usefulness.
Note - JBehave-Core creates files in the filesystem of the container, using the Subclassing
FilePrintStreamFactory class. This is probably configurable/extendable behavior if we create a specialized type of
StoryReporterBuilder that writes output to an in-memory stream. Needs more investigation.
StoryReporterBuilder is not easy and might not achieve the desired result.
- Note - StoryReporterBuilder.codeLocation is used to derive the value of StoryReporterBuilder.outputDirectory() which is eventually used as the outputDirectory to write reports to. The reports are generated in the
relativeDirectory named sub-directory under the
StoryReporterBuilder.withRelativeDirectory(...) methods could be used to direct JBehave to write reports to a shared directory e.g. target/jbehave. JBehave-Core does the necessary activity of combining the results of the current execution with the existing reports stored at the
codeLocation. We must also warn users (via documentation) about the perils of naming their stories similarly; JBehave does not merge story reports if the names are the same (irrespective of them being present in different locations).
We could write the reports to a shared location; but, this would result in reports being overwritten, instead of the reports being merged.
- Note - The stylesheets, images and other resources required by the reports are present in the
org.jbehave.site:jbehave-site-resources:zip:3.1.1 artifact, and would need to be downloaded and extracted before running the scenarios (Wat!!). See the logic in the
UnpackViewResources Mojo of the
- JBehave-Core depends on a lot of other libraries like Commons IO, Commons Collections etc. Unlike other Arquillian extensions, writing a
DeploymentAppender for embedding JBehave-Core in a deployment isn't easy, since it is quite difficult to ascertain all the packages and resources (like property files, stylesheets etc.) that would be needed. Also, future versions of JBehave-Core may undergo changes resulting in cumbersome changes to the DeploymentAppender. The MavenDependencyResolver simplifies this; however Maven resource-filtering must be used provide the JBehave-Core version to the DeploymentAppender at build time.
- Debate on
- Debate the usage of Guava MoreExecutors.sameThreadExecutor in an new class -
ArquillianStory, and the necessity to pack Guava in the deployment
- Consider the initialization of WebDriver instance per step/steps/scenario, just as performed in jbehave-web.
- Documentation on StoryReporterBuilder.withCodeLocation and StoryReporterBuilder.withRelativeDirectory to be produced