How to use getDescription method of net.serenitybdd.jbehave.runners.SerenityReportingRunner class

You can try importing Spring libraries and create a singleton object for the driver your created. By this you can share the same browser session from anywhere. To have a new browser for the second instance, quit the browser session in the singleton object and redefine it.

I had the same problem with a similar project. The reason why surefire didn't count the serenity test results was because the POM contained JUnit and TestNG artifacts. The TestNG artifact was added via a parent POM.

After I removed the TestNG dependency the report showed the number of tests executed.

See if reverting to previous version of jbehave helps . There seems to be a bug with the 4.0.4 . See this link https://groups.google.com/forum/#!topic/jbehave-dev/7OxwmOXZPVk

Serenity has this feature now

18. Running Serenity tests in parallel batches

http://thucydides.info/docs/serenity-staging/#_running_serenity_tests_in_parallel_batches

If you are using Maven take a look at Maven Failsafe plugin Rerun Failing Tests feature:

http://maven.apache.org/surefire/maven-failsafe-plugin/examples/rerun-failing-tests.html

WebdriverIO is a JavaScript / nodejs implementation of the (Selenium 2.0) WebDriver API - one of many (Selendroid, Protractor, etc.) As the specification says:

WebDriver is a remote control interface that enables introspection and control of user agents. It provides a platform- and language-neutral wire protocol as a way for out-of-process programs to remotely instruct the behaviour of web browsers.

If you use Java, you'll use the Java implementation of WebDriver. Which language, and which implementation you choose, is up to you, your skills, and the skill of your team.

Though I very much doubt that WebdriverIO is "not mature enough". WebDriver is a fine spec, with a number of powerful implementations, but it is very frequently misused. Certainly as far as newbies go, a very large proportion of "random" failures are completely avoidable race conditions within their test code.

You can use Meta: to tag stories/scenarios. This is useful if you want to run just subset of stories/scenarios or skip some of them. Example:

Meta: @sometag

Scenario: some scenario
Given something 

Then you can use meta filtering and story mapping to include/exclude scenarios marked with certain tags.

You can change story file names so their lexicographical order will match order you want them to execute:

1_aaa.story  
2_bbb.story
3_ccc.story

or create separate folders:

a/aaa.story
a/bbb.story
c/ccc.story

There is more nice solution in case when you need some story to execute before another one, GivenStories: clause:

GivenStories: aaa.story

Scenario: requires aaa to run
Given something

This will first execute aaa.story then this story. You can specify several stories in GivenStories.

If you need to continue after a failed step, you should use soft assertions.

I solved this using the following hack (basically injecting the service(s) myself):

@ContextConfiguration(locations = "test-beans.xml", 
                      loader = TestContextLoader.class)
public class GreetingServiceTest extends SerenityStories {

    @Autowired
    private GreetingService greetingService;

    private String greeting;

    @When("I want a greeting")
    public void whenIWantAGreeting() {
        greeting = greetingService.getGreeting();
    }

    @Then("I shall be greeted with \"$greeting\"")
    public void thenIShallBeGreetedWith(String greeting) {
        assertEquals(greeting, this.greeting);
    }

    @Override
    public InjectableStepsFactory stepsFactory() {
        return new InstanceStepsFactory(configuration(), this);
    }

    @BeforeStories
    public final void beforeStories() {
        AutowireCapableBeanFactory beanFactory = getContext().getAutowireCapableBeanFactory();
        beanFactory.autowireBeanProperties(this, AutowireCapableBeanFactory.AUTOWIRE_NO, false);
        beanFactory.initializeBean(this, getClass().getName());
    }

    private ApplicationContext getContext() {
        return SpringClassRuleHack.getTestContextManager(getClass())
            .getTestContext()
            .getApplicationContext();
    }
}

SpringClassRuleHack (must be the same package as SpringClassRule to get access to the getTestContextManager method):

package org.springframework.test.context.junit4.rules;

import org.springframework.test.context.TestContextManager;

public final class SpringClassRuleHack {

   private SpringClassRuleHack() {}

   public static TestContextManager getTestContextManager(Class<?> testClass) {
      return SpringClassRule.getTestContextManager(testClass);
   }

}

I'm getting the Spring context through SpringClassRule so that it gets cached by Spring, letting Spring control when the context needs reloading (if I have understood correctly).

I'm not entirely satisfied with this solution and I suspect it's not equivalent to enabling SpringClassRule/SpringMethodRule in the standard way, but it works in my case.