Running Stories

JBehave is designed to be embedded in different development environments. The JBehave Core module contains support for running stories as JUnit tests - which can be run either in your favourite IDE or in your command-line build that supports JUnit tests. Other unit testing frameworks, e.g. TestNG or Spring Test, can also be used very easily, c.f. FAQ.

You can also run stories using the JBehave Ant tasks or Maven goals, which provide a facade around the Embedder functionality.

JBehave provides the Embedder as the core entry point to running stories. The Embedder can be configured in multiple way, c.f. the configuration.

Multiple running modes

Stories can be run in different modes:

  • as embeddables: An Embeddable is an abstraction of a running mode, which can run a single story, e.g. if extending JUnitStory or can run multiple stories, e.g. if extending JUnitStories. The Embeddable instances allow their configuration.
  • as paths: once we have specified an instance of an Embedder, with its configuration, we run stories specified by paths.
  • with annotated embedder runner: an AnnotatedEmbedderRunner is an implementation of the JUnit Runner, which allows annotated specification of the Embedder to be used to run the stories. C.f. configuration on how to use annotatations to configure the Embedder.
  • with annotated path runner: an AnnotatedPathRunner is an extension of AnnotatedEmbedderRunner which creates a JUnit suite containing each story path and resolving the path to a human readable form that plays nicely with any IDE that provides JUnit integration.

Running Stories in a framework-neutral way

The Embedder can also be used to run the stories in any IDE environment, without the need to extend any base class. In the following example we use JUnit annotatation to denote different running instances:

where the TraderEmbedder/URLTraderEmbedder define the configuration using the loading from the classpath and URL resources, respectively. E.g.:

Running Remote Stories

JBehave supports running both local and remote stories. To run remote stories, we need to use a URL-based loader with an appropriate remote code location. The difference w.r.t. the local run is minimal:

Ignoring failures in stories

By default, the story runners are configured to fail-fast, i.e. the execution will stop at first failed story (but will complete execution of the all the scenarios in the story first). To allow the generation of a complete stories view (reporting how many stories failed), the runners need to be enabled to run stories with ignoreFailureInStories flag set to true. In this way, all stories will run and the failure will be assessed only during the view generation. If any stories failed, the build will fail correspondingly. Should the need to ignore failure in the view arise (although generally not recommended), one can set the ignoreFailureInView flag to true.