Upgrade Guide 0.2

This section highlights the changes from the release 0.1 to the 0.2.

Backwards-incompatible changes

Macros, contexts, fixtures

To allow the usage of multiple context types, and steps without one, the context declaration has been moved inside the step definition instead of being a parameter of the GIVEN/WHEN/THEN macro. Fixtures are NOT supported anymore. Contexts are now regular classes (or structs, of course).

Step definitions do not need a name and a context anymore. Regular expression parameters do not need to specify the position any longer, but they should be declared in the order they appear in the expression.

struct Ark {
    map<int, string> animals;
    void boardAnimal(string species, string quantity) {
        ...
    }
};

GIVEN("^The animals went in (\\w+) by \\1, the (\\w+) and the (\\w+)$") {
    REGEX_PARAM(string, quantity);
    REGEX_PARAM(string, firstAnimal);
    REGEX_PARAM(string, secondAnimal);
    USING_CONTEXT(Ark, ark);
    ark->boardAnimal(firstAnimal, quantity);
    ark->boardAnimal(secondAnimal, quantity);
}

New features

Boost and CppSpec test driver support

Support for CppSpec and Boost Test has been introduced.

This is how it looks the Calc sample using CppSpec.

#include <CppSpec/CppSpec.h>
#include <cukebins/wireserver.hpp>

#include <Calculator.h>

...

THEN("^the result should be (.*) on the screen$") {
    REGEX_PARAM(double, expected);
    USING_CONTEXT(CalcCtx, context);
    specify(context->result, should.equal(expected));
}

This is how it looks with Boost.

#include <boost/test/unit_test.hpp>
#include <cukebins/wireserver.hpp>

#include <Calculator.h>

...

THEN("^the result should be (.*) on the screen$") {
    REGEX_PARAM(double, expected);
    USING_CONTEXT(CalcCtx, context);
    BOOST_CHECK_EQUAL(expected, context->result);
}

The Calc example can be run using each testing framework through the GTestCalculatorSteps, CppSpecCalculatorSteps and BoostCalculatorSteps executables.

Hooks

Hooks are now supported, along with tags. An example of tag usage is provided in the source repository. This is the hook syntax:

BEFORE() {
   ...
}

AROUND_STEP("@cucumis,@sativus") {
   ...
   step->call();
   ...
}

AFTER_STEP("@cucumis", "@sativus") {
   ...
}

AFTER("@cucumis,@sativus", "@aqua") {
   ...
}

Only the hooks that match the scenario tags are run (the tag syntax is the same as the original Ruby one). Please note that the hooks are not executed in any predefined order other than that defined by their type; it means two hooks of the same type can be executed in any order, despite how they are declared. The supported types are:

• BEFORE: run before every scenario
• AFTER: run after every scenario
• AROUND_STEP: wraps the step call (and needs to invoke step→call() to go down the execution chain)
• AFTER_STEP: run after each step

There is no AROUND scenario hook like in Ruby.

Table arguments

Now you can pass table arguments to step definitions (GIVEN, WHEN or THEN). The parameter is not part of the regex, but instead it is an extra argument. Of course, regex matches are handled in addition to the table parameter. An example of table arguments usage is provided as well. This is the syntax:

GIVEN("table param not in this regex") {
    TABLE_PARAM(table);
    for (table_hashes_type::const_iterator i = table.hashes().begin(); i != table.hashes().end(); ++i) {
        // Do something...
    }
}

Pending steps

A step can be marked as pending by calling the “pending” method inside the step body.

WHEN("a regex (\\w+)") {
    REGEX_PARAM(string, justAParam);
    pending();
}

THEN("another regex") {
    pending("reason why it's pending");
}

Multiple files support

To compile features from multiple source files, the macro CUKE_OBJECT_PREFIX can be defined and it has to be different for every file. If not defined, it defaults to “CukeObject”.

Take a look at issue #36 for further details.