Handling Work-in-progress with Thucydides and JBehave Using @pending and @wip Tags

thucydides version 0.9.268 has just been released, with a few very interesting new features. thucydides is an open source reporting library that helps you write more effective bdd-style automated acceptance criteria, and generate richer test reports, requirements reports and living documentation. in this article, we will look at some of the new ways this version lets you handle work-in-progress or pending scenarios with thucydides and jbehave.

in jbehave, a scenario is considered passing if all of the step definitions are implemented, even if there is no code. this is because there is no obligation to use step libraries within the step definitions, though it is a good practice for more complex tests. consider the following scenario:

scenario:logging on via facebook

givenjoeis a frequentflyer member

andjoe has registered online via facebook

whenjoe logs on with a facebook token

then he should be given access to the site

when you execute this with no step definitions, it will be reported as pending, as illustrated here:

when you implement the steps, they will be considered successful unless an exception is thrown or a step is marked as pending. so the following will indeed pass:

 @given("$username has registered online via facebook")

    public void has_registered_via_facebook(string username){}

this is because there is no way to know that a step definition is empty - we can only know that no @step methods were called, which does not necessarily mean that it is empty.

you can make this a pending step by using the org.jbehave.core.annotations.pending pending annotation, e.g:

@pending
    @given("$username has registered online via facebook")
    public void has_registered_via_facebook(string username) {}

jbehave and thucydides will now report this scenario as pending, even though it has an "implemented" (albeit empty) step definition:

this is also a good way to keep track of work if you are driving the code from the step definitions, as you can easily see which steps have been done at any point in time.

the @ignore tag lets you skip a story during test execution, so that it does not appear in the reports.

meta:

@ignore



scenario:logging on via facebook

givenjoeis a frequentflyer member

andjoe has registered online via facebook

whenjoe logs on with a facebook token

then he should be given access to the site

if you want a scenario to appear in the report, but to mark it as 'pending' even if it fails, you can use the @pending tag directly within the story files, e.g.

meta:

@pending



scenario:logging on via facebook

givenjoeis a frequentflyer member

andjoe has registered online via facebook

whenjoe logs on with a facebook token

then he should be given access to the site



scenario:logging on via twitter

givenjoeis a frequentflyer member

andjoe has registered online via facebook

whenjoe logs on with a facebook token

then he should be given access to the site

or, for an individual scenario:

scenario:logging on via facebook

meta:

@pending



givenjoeis a frequentflyer member

andjoe has registered online via facebook

whenjoe logs on with a facebook token

then he should be given access to the site

in this case, the entire scenario or story/feature will be reported as 'pending':

you can also distinguish between work that hasn't been started yet and work that is in progress but not yet complete. the @skip or @wip tags will act like the @pending tag, but will report the scenario or story as "skipped".

scenario:logging on via facebook

meta:

@wip



givenjoeis a frequentflyer member

andjoe has registered online via facebook

whenjoe logs on with a facebook token

then he should be given access to the site

these will appear differently in the reports, as shown here:

this is a good way to identify what features are currently being worked on.

the following table summaries these options: