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

       Peter Sergeant "pete@clueball.com"

       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.

         Copyright 2019-2023, Erik Huelsmann
         Copyright 2011-2019, Peter Sergeant; Licensed under the same terms as Perl

perl v5.40.1                                       2025-05-29                  Test::BDD::Cucumber::Harness(3pm)

featurefeature_done
       Called at the start and end of feature execution respectively. Both methods accept a single argument of a
       Test::BDD::Cucumber::Model::Feature.

   backgroundbackground_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?)

   scenarioscenario_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.

   scenario_skip
       Called instead of "scenario" and "scenario_done" when a scenario is skipped.  Although the only reason
       for skipping scenarios currently is being excluded due to tag expressions, this may change in the future.

   stepstep_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_stepsub_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.

   startupshutdown
       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.

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

       version 0.87