Skip to content

Instantly share code, notes, and snippets.

@VineetReynolds

VineetReynolds/Readme.md

Created February 6, 2012 17:38
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save VineetReynolds/1753566 to your computer and use it in GitHub Desktop.
Save VineetReynolds/1753566 to your computer and use it in GitHub Desktop.
Download ZIP
Proposed Features for the Arquillian-JBehave Integration
Raw
Readme.md

Features for the Arquillian-JBehave integration

  • 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 @Observing the 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 Instance<T> types.
  • 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 TestEnricher approach.
  • Feature: Support for annotated configuration like @UsingPaths, @UsingSteps etc.
  • Note - Better to defer these, as they're used by AnnotatedEmbedderRunner and 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 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. Subclassing 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 codeLocation. The StoryReporterBuilder.withCodeLocation(...) and 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-maven-plugin.

Other facts to consider

  • 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.

Future actions

  • Debate on jbehave-maven-plugin:unpack-view-resources vs ViewResourcesUnpacker
  • 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment