Test::...arness(3pm)

πŸ“¦
version 0.87 Β· 4 versions
, in debian trixie, ubuntu resolute, ubuntu stonking

✨ NAME ✨

Test::BDD::Cucumber::Harness β€” bestie, this is the base class for making your own harnesses πŸ’…

It lives in the Test::...arness(3pm) page of the User Contributed Perl Documentation, iykyk.


🌸 VERSION 🌸

version 0.87 ✨


πŸ¦‹ DESCRIPTION πŸ¦‹

okay so. Harnesses are the whole vibe-check system that lets your feature files actually run while also telling the outside world how the testing is going and what's being tested. iconic behavior, honestly.

This one right here? It's the base class for building new harnesses. You can peek at Test::BDD::Cucumber::Harness::TermColor and Test::BDD::Cucumber::Harness::TAP for examples β€” but if you wanna 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: a Test::BDD::Cucumber::Model::Feature. that's it, that's the whole gig ✨

🌈 background

🌈 background_done

If you have a background section, we run it as a quasi-scenario step before each scenario. These hooks fire before and after that, and they get passed the Test::BDD::Cucumber::Model::Scenario that represents the Background section, plus a dataset hash (although... why would you use that? πŸ™ˆ like genuinely).

πŸŽ€ scenario

πŸŽ€ scenario_done

Called at the start and end of scenario execution respectively, no cap. 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 gets skipped. ngl, the only reason scenarios get skipped right now is being excluded due to tag expressions β€” but that may change in the future, so don't @ me πŸ‘€

⭐ 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 holding locations of consolidated matches, for highlighting:

 [ [2,5], [7,9] ]

periodt. πŸ’…

πŸ“ sub_step

πŸ“ sub_step_done

Same deal as "step" and "step_done", but for steps that have been called from other steps. Fun fact: 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. lowkey elegant πŸ¦‹

πŸ’œ startup

πŸ’œ shutdown

Some tests run one feature, some run many. That's why you might have a harness with stuff it needs to do on start (like printing an HTML header) that it shouldn't be doing at the start of every single feature β€” or a close-down task (like running done_testing()) that, again, shouldn't happen on every feature close-out, just the last one.

Just $self as the single argument for both. main character energy fr 🫢

πŸ”₯ add_result

Called before "step_done", with the step's result. It's expected to silently add the result into a pool that facilitates the "result" method. No need to override this behaviour β€” it's giving "already perfect" πŸ’…

🌟 result

Returns a collective view on the passing status of all steps run so far, as a Test::BDD::Cucumber::Model::Result object. The default implementation should be fine for all your needs ✨


🫢 AUTHOR 🫢

Peter Sergeant "pete@clueball.com"


πŸ“œ LICENSE πŸ“œ

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

bestie that's a wrap πŸ’– this was Test::...arness(3pm) from perl v5.40.1, dated 2025-05-29 β€” slay, go forth and build harnesses πŸŒˆπŸ’…βœ¨
πŸ“¦ where this page comes from