NAME

       Test::BDD::Cucumber::Harness - Base class for creating harnesses

VERSION

       version 0.83

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::TAP 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::Cucumber::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::Cucumber::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::Cucumber::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] ]

   sub_step
   sub_step_done
       As per "step" and "step_done", but for steps that have been called from other steps. None
       of the included harnesses respond to these methods, because generally the whole thing
       should be transparent, and the parent step handles passes, failures, etc.

   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 2019-2021, Erik Huelsmann
         Copyright 2011-2019, Peter Sergeant; Licensed under the same terms as Perl