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, can also be used very easily, c.f. FAQ.
You can also run stories using the JBehave Ant or Maven extensions. Both support two way to lookup stories, by list of story classes or by Java path includes/excludes pattern. Below are examples on how to configure both extensions - using the trader example.
JBehave provides a StoryEmbedder as an entry point to running stories. The embedder allows the specification of the configuration and the candidate steps. Then one needs only to specify the paths of the stories to run.
The StoryEmbedder can also be used to run the stories in any IDE environment, e.g. via JUnit, without the need to extend any base class.
where the Classpath/URLTraderStoryEmbedder define the configuration using the loading from the classpath and URL resources, respectively. E.g.:
Remember to include jbehave-ant to your runtime classpath.
Note: we are using as default scope compile, which means that the stories will be looked up in the source directory (which can be optionally specified and defaults to src/main/java). If the scope is set to test the stories will be looked up in the test source directory (which can be optionally specified and defaults to src/test/java).
Note: we are using as default scope compile, which means that the stories will be looked up in the POM source directory. If the scope is set to test the stories will be looked up in the POM test source directory.
By default, the story runners are configured to fail-fast, i.e. the execution will stop at first failure (but will complete execution of the all the stories in the story or textual story file). To allow the generation of complete reports view, the runners need to be enabled to execute story in batch and ignoreFailure modes (i.e. setting these flags to true). In this way all stories will run and the build will be nominally successful but a full report can ben generated, including the failed and pending steps. Note that the batch mode is strictly speaking not essential but makes it easier to get a summary of the failed stories.