NAME¶
Test::BDD::Cucumber::Harness - Base class for creating harnesses
VERSION¶
version 0.26
DESCRIPTION¶
Harnesses allow your feature files to be executed while telling the outside
world about how the testing is going, and what's being tested. This is a base
class for creating new harnesses. You can see
Test::BDD::Cucumber::Harness::TermColor and
Test::BDD::Cucumber::Harness::TestBuilder for examples, although if you need
to interact with the results in a more exciting way, you'd be best off
interacting with Test::BDD::Cucumber::Harness::Data.
METHODS / EVENTS¶
feature¶
feature_done¶
Called at the start and end of feature execution respectively. Both methods
accept a single argument of a Test::BDD::Cucumber::Model::Feature.
background¶
background_done¶
If you have a background section, then we execute it as a quasi-scenario step
before each scenario. These hooks are fired before and after that, and passed
in the Test::BDD::Cucmber::Model::Scenario that represents the Background
section, and a a dataset hash (although why would you use that?)
scenario¶
scenario_done¶
Called at the start and end of scenario execution respectively. Both methods
accept a Test::BDD::Cucmber::Model::Scenario module and a dataset hash.
step¶
step_done¶
Called at the start and end of step execution respectively. Both methods accept
a Test::BDD::Cucmber::StepContext object. "step_done" also accepts a
Test::BDD::Cucumber::Model::Result object and an arrayref of arrayrefs with
locations of consolidated matches, for highlighting.
[ [2,5], [7,9] ]
startup¶
shutdown¶
Some tests will run one feature, some will run many. For this reason, you may
have harnesses that have something they need to do on start (print an HTML
header), that they shouldn't do at the start of every feature, or a close-down
task (like running "done_testing()"), that again shouldn't happen on
every feature close-out, just the last.
Just $self as the single argument for both.
add_result¶
Called before "step_done" with the step's result. Expected to silently
add the result in to a pool that facilitate the "result" method. No
need to override this behaviour.
result¶
Returns a collective view on the passing status of all steps run so far, as a
Test::BDD::Cucumber::Model::Result object. Default implementation should be
fine for all your needs.
AUTHOR¶
Peter Sergeant "pete@clueball.com"
LICENSE¶
Copyright 2011-2014, Peter Sergeant; Licensed under the same terms as Perl