We can run our scenarios with the following Gradle command:

$ gradle clean test

Gradle only runs tasks that changed from the last execution. Since our source code will not always change (we often modify only stories in text format), the clean task is required to be run before the test so that the cache is removed.

JBehave creates a nice report for us and puts it into the target/jbehave/view directory. Open the reports.html file in your favorite browser.

The initial page of the report displays a list of our stories (in our case, only Administration) and two predefined ones called BeforeStories and AfterStories. Their purpose is similar to the @BeforeClass and @AfterClass JUnit annotated methods. They are run before and after stories, and can be useful for setting up and tearing down data, servers, and so on.

This initial reports page shows that we have five scenarios and all of them are in the Pending status. This is JBehave's way of telling us that they were neither successful nor failed, but that there is code missing behind the steps we used:

The last column in each row contains a link that allows us to see details of each story:

In our case, all the steps are marked as pending. JBehave even puts a suggestion of a method that we need to create for each pending step.

To recapitulate, at this point, we wrote one story with five scenarios. Each of those scenarios is equivalent to a specification that will be used both as a definition that should be developed and to verify that the development was done correctly. Each of those scenarios consists of several steps that define preconditions (Given), actions (When), and the expected outcome (Then).

Now it is time, to write the code behind our steps. However, before we start coding, let us get introduced to Selenium and Selenide.