Automated Acceptance-Testing using JBehave

37 Comments

Introduction

Nowadays Agile Teams can choose from a wide variety of tools for automating Acceptence Tests. Thereby a lot of quite different concepts show up. FitNesse for example is using an integrated Wiki to organise testcases, while the Robot Framework is using keyword-driven test development. These are examples of two well-established tools in this area. These tools have a rich scope of operation, but therefore they also require a longer period of vocational adjustment.

In comparison JBehave seems to be very lightweight on first sight (and also on second sight). There is the description of the testcases in BDD-format on one side and the implementation of the required test functionality in Java on the other side. Both parts can be easily connected using Maven.

As this article is a bit longer a short overview on the topics that follow is given here:

  • Maven Configuration: Explains the required configuration for Maven to implement and execute tests using JBehave.
  • Testcases: Shows how testcases are written in JBehave using the BDD-format.
  • Implementation: Explains the required steps to implement the test functionality in Java that is matching the description of certain testcases.
  • Reporting: Showing the results of a test execution with JBehave.
  • Putting the pieces together: Maven, description of testcases and implementation of test functionality are glued together using certain naming and directory conventions.
  • Conclusion: How suitable is JBehave for automating Acceptance Tests? And for whom?
  • Download: Download the complete example as a ZIP-file.

Ship’s log supplement as of 16.06.2012: My collegue Andreas has written a very good article on the various configuration possibilities of JBehave.. This one could be surely of great help after starting with JBehave :-).

Maven Configuration

For projects that are developed using Java, JBehave has definitely the big advantage that the integration to the existing development environment of the team works very smoothly. This is especially the case if Maven is already used as the build tool. Of course this is working for other testing tools as well. But especially if these tools are not initially developed in and for Java this often gets more complicated than desired.

The following Maven configuration is sufficient to start with the development of Acceptance Tests with JBehave. Tests can be compiled, started and even artifacts required for the reporting can be downloaded with this:

<?xml version="1.0" encoding="UTF-8"?>
 
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
 
  <url>http://maven.apache.org</url>
  <modelVersion>4.0.0</modelVersion>
  <name>JBehaveDemo</name>
  <groupId>de.codecentric</groupId>
  <artifactId>jbehave-demo</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
 
  <dependencies>
    <dependency>
      <groupId>org.jbehave</groupId>
      <artifactId>jbehave-core</artifactId>
      <version>3.1.2</version>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.4</version>
    </dependency>
  </dependencies>
 
  <build>
    <plugins>
      <plugin>
        <groupId>org.jbehave</groupId>
        <artifactId>jbehave-maven-plugin</artifactId>
        <version>3.1.2</version>
        <executions>
          <execution>
            <id>run-stories-as-embeddables</id>
            <phase>integration-test</phase>
            <configuration>
              <includes>
                <include>**/*Scenarios.java</include>
              </includes>
              <ignoreFailureInStories>true</ignoreFailureInStories>
              <ignoreFailureInView>false</ignoreFailureInView>
           </configuration>
           <goals>
              <goal>run-stories-as-embeddables</goal>
           </goals>
         </execution>
       </executions>
     </plugin>
 
     <plugin> 
       <groupId>org.apache.maven.plugins</groupId> 
       <artifactId>maven-dependency-plugin</artifactId> 
       <executions> 
         <execution> 
            <id>unpack-jbehave-site-resources</id>
            <phase>generate-resources</phase> 
            <goals> 
               <goal>unpack</goal> 
            </goals> 
            <configuration> 
               <overwriteReleases>false</overwriteReleases> 
               <overwriteSnapshots>true</overwriteSnapshots> 
               <artifactItems> 
                  <artifactItem> 
                     <groupId>org.jbehave.site</groupId> 
                     <artifactId>jbehave-site-resources</artifactId> 
                     <version>3.1.1</version> 
                     <type>zip</type>
                     <outputDirectory> ${project.build.directory}/jbehave/view</outputDirectory> 
                   </artifactItem> 
                </artifactItems> 
            </configuration> 
         </execution> 
         <execution> 
            <id>unpack-jbehave-reports-resources</id>
            <phase>generate-resources</phase> 
            <goals> 
               <goal>unpack</goal> 
            </goals> 
            <configuration> 
              <overwriteReleases>false</overwriteReleases> 
              <overwriteSnapshots>true</overwriteSnapshots> 
              <artifactItems> 
                 <artifactItem> 
                   <groupId>org.jbehave</groupId> 
                   <artifactId>jbehave-core</artifactId> 
                   <version>3.1.2</version> 
                   <outputDirectory>${project.build.directory}/jbehave/view</outputDirectory> 
                   <includes>**\/*.css,**\/*.ftl,**\/*.js</includes> 
                 </artifactItem> 
               </artifactItems> 
             </configuration> 
           </execution> 
         </executions> 
       </plugin> 			
     </plugins>
  </build>
</project>

As said with this configuration all required Jar files are downloaded automatically and the tests can be started using the command: “mvn integration-test”. Of course we need some testcases and implementation of test functionality for this to work.

Testcases

JBehave supports the so-called BDD-format (Given/When/Then) for writing testcases. This format has the following syntax:

Given:    a static precondition
And:    another static precondition
And:   
When:    tested behaviour
And:    more tested behaviour
And:   
Then:    the result of the tested behaviour under the given preconditions
And:   

This format has the big advantage that it can be read quite easily also from non-technical people. This enables the team to establish a common understanding between the development team and members of the operating departments and/or customers.

Writing automated Acceptance Tests is a task that – in an ideal case – is always performed in close cooperation between the experts of the operating departments and the agile development team. This ensures that really all required compentences are available and that first results from the test execution can be analysed quickly together. A description of the testcases that is easily understood by all involved parties is of course a mandatory precondition for this to work.

In JBehave the testcases are written in co-called story-files. Thereby it is a meaningful convention that in one of these story-files all tests for one user story are described. It is already taken care of when writing user stories that those do not become too big. This ensures that the amount of testcases in these story-files are as well kept at a reasonable level. In addition this is supported by the clear structure of the story-files. Testcases are by the way called “scenarios” in JBehave.

To keep this example as simple as possible the tests are written for the existing stack implementation of Java. This way the use case is very simple and the focus can be fully put on the concepts and correlations of JBehave.

Narrative:
In order to develop an application that requires a stack efficiently
As a development team
I would like to use an interface and implementation in Java directly
 
 
Scenario:  Basic functionality of a Stack
 
Given an empty stack
When the string Java is added
And the string C++ is added
And the last element is removed again
Then the resulting element should be Java
 
Scenario:  Stack search
 
Given an empty stack
When the string Java is added
And the string C++ is added
And the string PHP is added
And the element Java is searched for
Then the position returned should be 3

At the beginning of a story-file it is possible to explain the tested user story once again. This is happening after the keyword Narrative:. Of course it makes sense to repeat here – a hopefully already existing description – of the user story. But as this text is anyway completely ignored with respect to the testing functionality, any text can be put here in the end.

Especially for tests written in the BDD-format it makes much sense to write them in your native language. In the example above the tests are written in English language as this is supported out-of-the-box by JBehave. But it is possible to translate the used keywords (Given/When/Then) into other languages as well doing some additional coding in Java.

After this any amount of testcase (=Scenarios) can be written. Those are always started with the keyword Scenario: followed by a brief description of this testcase. Then the actual definition of the testcase is given.

Implementation

Mapping the description of the testcases to the corresponding implementation is really simple. Each row in the description of the testcases (in JBehave those are called steps) is mapped to a corresponding method in a Java class. The methods are marked with the proper annotations defined by JBehave. Passing parameters is handled using a naming convention ($variable) in the annotations. Of course those must then be as well defined as parameters in the method definitions.

package de.codecentric.jbehave;
 
import java.util.Stack;
import org.jbehave.core.annotations.*;
import org.jbehave.core.embedder.Embedder;
import junit.framework.Assert;
 
public class StackStories extends Embedder{
 
    private Stack<String> testStack;
    private String searchElement;
 
    @Given("an empty stack")
    public void anEmptyStack() {
        testStack = new Stack<String>();
    }
 
    @When("the string $element is added")
    public void anElementIsAdded(String element) {
        testStack.push(element);
    }
 
    @When("the last element is removed again")
    public void removeLastElement() {
        testStack.pop();
    }
 
    @When("the element $element is searched for")
    public void searchForElement(String element) {
        searchElement = element;
    }
 
    @Then("the resulting element should be $result")
    public void theResultingElementShouldBe(String result) {
    	Assert.assertEquals(testStack.pop(), result);
    }
 
    @Then("the position returned should be $pos")
    public void thePositionReturnedShouldBe(int pos) {
    	Assert.assertEquals(testStack.search(searchElement), pos);
    }
}

The class shown above implements the so-called steps from the test descriptions. To be able to execute the tests from a story-file an additional Java class is required. This class is mapped to a story file using some naming conventions and furthermore some common settings (like reporting) are defined in this class:

package de.codecentric.jbehave;
 
import java.net.MalformedURLException;
import java.net.URL;
import java.util.List;
 
import org.jbehave.core.configuration.Configuration;
import org.jbehave.core.configuration.MostUsefulConfiguration;
import org.jbehave.core.io.LoadFromRelativeFile;
import org.jbehave.core.junit.JUnitStory;
import org.jbehave.core.reporters.StoryReporterBuilder;
import org.jbehave.core.reporters.StoryReporterBuilder.Format;
import org.jbehave.core.steps.CandidateSteps;
import org.jbehave.core.steps.InstanceStepsFactory;
import org.junit.Test;
 
public class StackScenarios extends JUnitStory {
 
    @Override
    public Configuration configuration() {
        URL storyURL = null;
        try {
            // This requires you to start Maven from the project directory
            storyURL = new URL("file://" + System.getProperty("user.dir")
                    + "/src/main/resources/stories/");
        } catch (MalformedURLException e) {
            e.printStackTrace();
        }
        return new MostUsefulConfiguration().useStoryLoader(
                new LoadFromRelativeFile(storyURL)).useStoryReporterBuilder(
                new StoryReporterBuilder().withFormats(Format.HTML));
    }
 
    @Override
    public List<CandidateSteps> candidateSteps() {
        return new InstanceStepsFactory(configuration(), new StackSteps())
                .createCandidateSteps();
    }
 
    @Override
    @Test
    public void run() {
        try {
            super.run();
        } catch (Throwable e) {
            e.printStackTrace();
        }
    }
}

The API of JBehave is offering some more possibilities, but these classes are sufficient to start testing. Unfortunately is the quality of the JavaDoc documentation of the API rather poor.

It should be noted that it is not mandatory to have an implementation for every step in the story-file right away. JBehave can handle situations where steps are missing and marks them then per default as “pending” in the report. This way tests can be written before the actual implementation must be there. The behaviour of JBehave with respect to this situation is configurable and if desired a missing step implementation can also result in an error.

Obviously it is very helpful being able to execute the tests directly from an IDE (e. g. Eclipse). This is working with JBehave very easily thanks to this unimposing method from the above shown class:

...
    @Override
    @Test
    public void run() {
        try {
            super.run();
        } catch (Throwable e) {
            e.printStackTrace();
        }
    }
...

With this tests can be directly executed with JUnit. I found this possibility by chance when trying things out as it was not stated explicitly in the documentation (or I have just not seen it). But this way tests can for example be started in the debugger quite nicely.

Reporting

The following screenshot shows the report generated by JBehave when executing the tests from this example:

The amount of information is not really overwhelming but sufficient. Especially the – in this kind of report – important information about the execution date and time is shown in the footer of the report. The two links at the end of the row are leading to the definition of the related story-file and a page displaying the execution statistics directly. The whole configuration of the reporting has for sure still some possibilities to explore. But for this overview this should be enough for the time being.

The report itsself if located in the directory target/jbehave/view of the Eclipse workspace after execution. It has the name reports.html. To make the report look pretty additional style information is required. And as we luckily have already made the corresponding entries in the POM-file we can download the required files easily using Maven:

mvn generate-resources

Afterwards there should be additional directories (ftl, images …) showing up below the directory target/jbehave/view.

Putting the pieces together

There are three important parts for developing Acceptance Tests with JBehave:

  • Maven Configuration: Once this one is working it is more or less static.
  • Testcases: A new story-file is added for every new user story. Of course existing scenarios might be changed or extended in the course of a project.
  • Implementation: The Java class required for executing the tests is more or less static. To add more stories it would make sense here to consider a generic super class. The implementation of the test functionality as such is happening in parallel to writing the testcases. These classes contain the real logic of the tests.

There are some naming conventions used in JBehave to glue certain things together. The following part of the POM-file is for example defining which classes are searched for to execute tests (=scenarios):

   ...
          <execution>
            <id>run-stories-as-embeddables</id>
            <phase>integration-test</phase>
            <configuration>
              <includes>
                <include>**/*Scenarios.java</include>
              </includes>
              <ignoreFailureInStories>true</ignoreFailureInStories>
              <ignoreFailureInView>false</ignoreFailureInView>
           </configuration>
           <goals>
              <goal>run-stories-as-embeddables</goal>
           </goals>
         </execution>
   ...

Based on the name of the “scenario class” – in this case StackScenarios.java – the corresponding story-file can be found. Therefore the story-file must have a name that matches the name of the “scenario class”, unless it is allowed to add additional underscores and the mapping is not case-sensitive. In our example the name of the story-file is stack_scenarios.story.

JBehave offers different possibilities to search for story-files. In our example an absolute path is used for this, which contains the current working directory. Therefore the tests must be executed from the project directory containing the POM-file. The name of the story-file is in addition prepended by the path that is mathcing the Java package of the scenario class. This must be considered when storing the story-files.

The scenario class contains a method that configures the class (or classes) that contain the required step definitions (methods):

...
    @Override
    public List<CandidateSteps> candidateSteps() {
        return new InstanceStepsFactory(configuration(), new StackSteps())
                .createCandidateSteps();
    }
...

The corresponding classes must be reachable via the classpath, but probably it would be quite hard to make the implementation in a way that those classes can not be found.

Conclusion

Due to the length of this article one might think that JBehave is not as lightweight as promised in the introduction. But this is not true as the example in this article is covering for sure 80%-90% of the required implementation to get started with writing Acceptance Tests in a real project. The effort for this of course highly depends on the complexity of the tested software/system. But this is true for every tool used. An advantage here is that Java developers can probably estimate quite easily what is supported already by existing libraries and how much effort is thus required for writing the final test code.

The structure of the story-files is simple and clean. Furthermore there are additional features like the usage of tables with test-data to iterate over some scenarios with different test values. It is also possible to use some meta statements in the story-files to influence the reporting if this is desired. The reporting looks sufficient on first sight and can be extended still according to the documentation.

The good integration with Maven and Eclipse is the big strength of JBehave and makes it especially interesting for Java developers. The possibility to execute the tests easily using JUnit (e. g. for debugging purposes) is an additional advantage here.

Integrating JBehave into a CI-environment (Continuous Integration) is easily possible due to the usage of Maven. Testing Web-Applications is in addition supported with an own web component that is based on Selenium and of course one has the freedom to use the Java selenium library right away.

My very personal conclusion: Getting started with JBehave is fun and is having only very few moments of frustration (mainly when reading the API documentation). And even though I am not the biggest Maven-fan on this planet I have to admit that the integration with Maven is well done and helpful. I could well consider using the tool in some real-life project. Of course there are also still some more things to explore. For me most interesting here would be support of different languages in the story-files and testing web applications. Hopefully some of these aspects can be checked out in some forthcoming blog article.

Download

Here all the files required for the example can be downloaded as one ZIP-file. Afterwards the project can for example be imported to Eclipse.

cc_JBehaveSample.zip

The project can then be build issuing the following command:

mvn compile

The required style-files for the reporting can be downloaded using this command (required only once):

mvn generate-resources

Afterwards the tests can be executed using this command:

mvn integration-test

All commands must be executed from the project directory that is also containing the pom.xml-file.

Author

Thomas Jaspers

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • March 25, 2011 von Seth

    Great article, I’ve been wondering about that generate sources goal! I’m currently working on integrating maven and jbehave and the CI server Hudson (now Jenkins). There is already a jbehave-hudson plug-in to help hudson aggregate the test results – I mention that only because it speaks to your point that jbehave is CI ready.

  • March 29, 2011 von Jonathan Major

    hi,

    good article thanks.

    can a scenario be called from another scenario?

    thanks
    Jonathan

  • April 1, 2011 von Remi

    Hi,

    Thanks you for your article, but I have just a problem, Indeed the story report is empty.

    Rémi

  • April 6, 2011 von Remi

    I talk about the report: view \ reports.html
    It’s quite difficult for me because the documentation is pretty complex for me …

    Rémi

  • Thanks for sharing
    Got the demo working. It is nice to try and to play / tailor it.

    Pascal

  • @Pascal: Great, nice to hear :-).

    @Remi: Strange you do not get the report … could not yet reproduce that problem.

  • May 19, 2011 von Pushparaj

    Hi,

    Thanks for the nice article. I am using selenium page objects with jbehave. In case any of my scenarios failed, i want to capture the screen shot. How to identify a failing scenario in JBehave and which class and method i need to extend and override?

    Thanks in advance,
    Pushparaj

  • May 20, 2011 von kotresh

    Hi

    how can i take error message screenshot in JBehave.
    for example :- if enter wrong user name and password in GMAIL . it will error message as “The username or password you entered is incorrect. [?]”. this screen i need catch in JBehave, and i using selenium with JBehave.

    could please help me regard this

    Regards,
    kotresh

  • I have not tried Selenium with JBehave yet, but my guess is that taking the screenshot as such is more a question of Selenium Java-API and not so much of JBehave itsself. Google provides some quick answers here I guess ;-).

    Regarding the failing scenario I would say it will fail in the corresponding step where you check the conditions – using Selenium – and they are not fulfilled. Probably you could then just throw an Exception to make the scenario fail.

  • May 25, 2011 von kotresh

    Hi
    One more help Thomas.
    can i run Jbehave java class in testNG ?
    Is there any limitation with testng ?

    i calling Jbehave java class like this

    But i am not able to run “StackScenarios” java class from testng.

    could please help regard this

    Regards
    kotresh

  • June 10, 2011 von Pankaj Nakhat

    @Pushparaj : You can identify the failing scenario by annotation themethod you want to call on failure by doing something like

    @AfterScenario(uponOutcome = Outcome.FAILURE)

    You can also do similarly

    @AfterScenario(uponOutcome = Outcome.SUCCESS)

  • June 22, 2011 von Chandra

    hi, You given a good working example for JBehave.
    i tried it, it’s working fine but i am not getting the report results properly.
    every time showing as showing zero results (for successful, pending, failed, for both steps and scenarios columns).
    can you help me regarding this?
    and let me know if you worked any Spring Jbehave examples.

    Thank You.

  • September 15, 2011 von Guillot Nicolas

    According to http://www.mail-archive.com/dev@jbehave.codehaus.org/msg05272.html “You’re missing the stats, which are used in the report generation. You can
    either invoke withDefaultFormats() on the StoryReporterBuilder, or add
    Format.STATS directly to withFormats().”

  • December 11, 2011 von Patrick Bernard

    Thanks a lot, that helped getting rid of these 0s.
    I started thinking my Eclipse was gone belly up yet again!

  • December 20, 2011 von Bhuvnesh Pratap

    I wish to use jBehave in completeness as an integration testing framework and therefore I need some definite way of setting up the Test data in the database before I begin with a particular test story something similar to using DbUnit with jUnit where we define the test data XMLs for each test case. Is there a way to achieve this with or with out DbUnit ?

  • March 13, 2012 von Manali

    Excellent article for beginers.I have started work in JBehave and looking into the report generated by jbehave.It seems that JBehave not gives the result as failed if my execution fails.For checking the reporting functionality provided in JBehave, I created a test which takes input from csv file(login credentials) and executed it.JBehave generates report after execution,but when I entered a wrong input through my csv file, Framework is showing me Java exception on eclipse console but showing storry as successful in report and nowhere I am able to find a way to take stack trace from the console to my report.Can anyone have idea how to get correct results in report generated in JBehave.
    Your help would be highly appericiated.

    Thanks,
    Manali

  • May 4, 2012 von JM

    Good introduction to JBehave! I’m about to start getting into JBehave.

    Couple of questions:
    – Is JBehave mainly a tool aimed for the developers?
    – What kind of technical skills you need to successfully create automation set with JBehave? I.E how much coding is involved with Java?
    – Is it suitable for non-technical QA people to use JBehave?

    -JM

  • Hi JM,

    in my opinion writing tests with JBehave is a joined effort (as with most of the Test Automation Tools).

    Writing the test functionality requires implementing those in Java and that is probably not possible for QA people, but must be done by developers. How much coding is required – and how complicated this might get – depends heavily on the application you are about to test.

    Once there is a set of “test functionality implementations” available, it is of course very much possible – and also wanted I would say – that QA people are then writing the actual tests using this functionality. Of course it requires some good documentation (and/or close cooperation with QA people) on the developers side, so that peolple writing the tests (scenarios) know what they can use.

    Using variants as described in the blog by my collegue here (http://blog.codecentric.de/en/2012/04/easier-jbehave-steps-with-variants/) could help writing the scenarios more easily.

    Hope that helps to some extend :-).

    Best Regards
    – Thomas

  • May 22, 2012 von keki

    how can we setup a BDD project from the very start

  • Hi Keki,

    well, basically I was hoping that this article is explaining exactly this :-). Do you have a more concrete question what your problems are in starting a BDD project?

    Best Regards
    – Thomas

  • May 30, 2012 von keki

    Hi Thomas,
    Your explanation was fullon and great, but I am not very familiar with maven, and I am looking at BDD from a Agile Automation Testers perspective. I did setup a practice project using maven and Eclipse, with an idea of running some scenarios on an existing web application.My test folder structure is src–test–pages, steps, stories. the other folders are the test folder, maven dependencies and jre system library

    When I try to run the story as a junit test it gives me an error message “no test found with test runner JUnit4″.

  • Great Article, just was doing a review on JBehave, comparing it with FitNesse, Cucumber and Concordion.

    I was so enjoying this article, that I want to ask your permission to publish it in my site, with your name and your blog link of course.

    Did you try to tools above?

    visit my site at http://www.qatestingtools.com

    we have now a new section called ‘Professional Assistance’ which is for registered users, there I am puting links to my favorite sites and blogs, thought about adding your blog as well.
    you can visit it at http://www.qatestingtools.com/assistance

    Thank you in advance and Best Regards
    Yuval Ben Hur

  • Hi Yuval,

    always nice to hear people are enjoying this article :).

    Of course you can reference it and I would be fine putting for example the Introduction-Section to your site and then linking here for the full article. Though I would not like to have the complete article copied to another site, sorry.

    When it comes to Concordion you might want to take a look on this article: http://blog.codecentric.de/en/2012/01/automated-acceptance-testing-using-concordion/

    For FitNesse I was doing some comparison with the Robot Framework some time ago: http://blog.codecentric.de/en/2009/08/fitnesse-vs-robotframework-agile-testing-tools/
    But that article is already quite ancient by now ;-).

    Best Regards
    – Thomas

  • January 3, 2013 von Chandrasekhar K

    we have two story files (story 1, story 2), in turn has two classes (class1Story1, class2Story2). It has one-one relation between story and classes. Is it possible to execute two stories in sequence while picking up class relevant to the store. If so, pl suggest to configure classes and stories.

  • January 9, 2013 von Adimor

    The example is great.
    i still have problem with the report – it show zero result for a success run.

  • September 12, 2013 von Prashant

    Hi Thomas,

    Thanks for detailed article. Can you please give your opinion about JBehave vs Robot Framework.
    I was thinking of Robot Framework looking at multiple readily available keyword libraries and very good reporting. I would appreciate some of your thoughts comparing both these tools.

    Thanks,
    Prashant

  • Hi Prashant,

    first of all sorry for the bit late reply :).

    From my experience I would say that developers tend to like JBehave more as you can do all the implementation work directly in your IDE (e.g. Eclipse) and do the debugging there when executing the tests and do refactoring and so on.

    On the other hand you might have like let’s say QA-people :) who would be able to implement tests with the Robot Framework and some ready made libraries, but would probably struggle to do the same with JBehave. (Of course writing new test variations on existing test functionality is probably equally easy in both tools.)
    RIDE can be very helpful in this case.

    The overall better reporting and I would also say better eco-system (active forum, etc.) is a + for the Robot Framework as well.

    Hope that helps a bit in judging, but in the end if this is a bigger problem some additional evaluation phase might be very helpful implementing a few tests in both tools to get a better grip on what works best for you :).

    Best Regards
    – Thomas

  • April 18, 2014 von Sandy

    Hi in eclipse, I am getting following error in POM.xml:

    “maven-dependency-plugin (goals “copy-dependencies”, “unpack”) is not supported by m2e.”

    What should be done.

  • June 6, 2014 von Giovanni

    Hi, thanks for your usefull tutorial, it’s the only one I’ve found for jbehave that works form me in Eclipse :-) … the only things that don’t works are the counts and totals for steps, scenarios, success etc. in the summary report table. Any idea why I cannot’s see any values (they are all zeros) even if I can see the correct report for my story (with 2 scenarios, 1 fail and 1 pass)? Thnks in advance

  • June 6, 2014 von Giovanni

    I solved it, I’m usign last stable jbehave 3.9.2 and its necessary to explicit Format.STATS as option for StoryReportBuilder .. so the statement new StoryReporterBuilder().withFormats(Format.HTML, Format.STATS) works!

  • Hi Thomas,

    Thanks for your sharing.
    When practice, I have a problem:

    My structure:
    src/test/jav
    –testPackage
    —-Example1.java
    —-MySteps.java
    src/test/resources
    –example1.story

    My problem is whenever I run, I met the error “Story path ‘testPackage/example1.story’ not found while looking in ‘[D:\Selen\Workspace\testJbehave\target\test-classes\*.story/testPackage/example1.story]'”

    Example1.java file:
    public class Example1 extends JUnitStory {
    @Override
    public Configuration configuration() {
    URL url = null;
    try{
    url = new URL(CodeLocations.codeLocationFromClass(this.getClass()),”*.story”);
    System.out.println(url.toString());
    }catch (Exception ex){
    ex.printStackTrace();
    }
    return new MostUsefulConfiguration()
    // where to find the stories
    //.useStoryLoader(new LoadFromClasspath(this.getClass()))
    .useStoryLoader(new LoadFromRelativeFile (url))
    // CONSOLE and TXT reporting
    //.useParameterControls(new ParameterControls().useDelimiterNamedParameters(true))
    .useStoryReporterBuilder(
    new StoryReporterBuilder().withDefaultFormats().withFormats(Format.CONSOLE, Format.TXT));
    }

    @Override
    public List candidateSteps() {
    return new InstanceStepsFactory(configuration(), new MySteps()).createCandidateSteps();
    }

    protected List storyPaths(){
    return new StoryFinder().findPaths(
    CodeLocations.codeLocationFromClass(this.getClass()),
    “*.story”, “”);
    }

    The console print url = file:/D:/Selen/Workspace/testJbehave/target/test-classes/*.story

    Many thanks,
    Hai

  • nice article Thomas,,

    Getting issues in running the scenario,, as this is not picking of any scenarios to run. please help.

    Console logs – ——————————————————-
    T E S T S
    ——————————————————-

    Results :

    Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

    [INFO]
    [INFO] — maven-jar-plugin:2.3.2:jar (default-jar) @ jbehave-demo —
    [INFO]
    [INFO] — jbehave-maven-plugin:3.1.2:run-stories-as-embeddables (run-stories-as
    -embeddables) @ jbehave-demo —
    [INFO] Running stories using embedder Embedder[configuration=org.jbehave.core.co
    nfiguration.MostUsefulConfiguration@39e48b4c,candidateSteps=[],classLoader=Embed
    derClassLoader[urls=[/C:/Users/dakojuu/Downloads/cc_JBehaveSample/target/classes
    /, jbehave-core-3.1.2.jar, commons-collections-3.2.1.jar, commons-io-1.4.jar, co
    mmons-lang-2.5.jar, plexus-utils-2.0.5.jar, freemarker-2.3.16.jar, junit-dep-4.8
    .2.jar, hamcrest-all-1.1.jar, junit-4.4.jar],parent=ClassRealm[plugin>org.jbehav
    e:jbehave-maven-plugin:3.1.2, parent: sun.misc.Launcher$AppClassLoader@405a02ef]
    ],embedderControls=UnmodifiableEmbedderControls[EmbedderControls[batch=false,ski
    p=false,generateViewAfterStories=true,ignoreFailureInStories=true,ignoreFailureI
    nView=false]],metaFilters=[],systemProperties={},storyMapper=StoryMapper,storyRu
    nner=StoryRunner,embedderMonitor=MavenEmbedderMonitor]
    [INFO] Found class names: [de.codecentric.jbehave.StackScenarios]
    [INFO] Running embeddable de.codecentric.jbehave.StackScenarios
    [INFO] Processing system properties {}
    [INFO] Running story de/codecentric/jbehave/stack_scenarios.story
    [INFO] Generating reports view to ‘C:\Users\dakojuu\Downloads\cc_JBehaveSample\t
    arget\jbehave’ using formats ‘[html]’ and view properties ‘{viewDirectory=view,
    views=ftl/jbehave-views.ftl, reports=ftl/jbehave-reports-with-totals.ftl, decora
    teNonHtml=true, nonDecorated=ftl/jbehave-report-non-decorated.ftl, decorated=ftl
    /jbehave-report-decorated.ftl, defaultFormats=stats, maps=ftl/jbehave-maps.ftl}’

    [INFO] Reports view generated with 1 stories containing 0 scenarios (of which 0
    failed)
    [INFO] ————————————————————————

Comment

Your email address will not be published. Required fields are marked *