Provided by: libtest-bdd-cucumber-perl_0.60-1_all bug


       Test::BDD::Cucumber::Manual::Architecture - Structural Overview


       version 0.60


       This short document exists to give you an idea how the different components of this
       distribution fit together. Components fall into three categories: one for dealing with
       definition of the step functions (Perl code), the other for dealing with feature files.
       And then there's the third group, with "Test::BDD::Cucumber::Executor" which links the two
       groups together; building on the steps to execute the features.

       In the first group are "Test::BDD::Cucumber::StepFile" and "Test::BDD::Cucumber::Loader".
       The second group is bigger and is comprised of

       ·   "Test::BDD::Cucumber::Parser"

       ·   "Test::BDD::Cucumber::Model::*"

       The third group holds - next to "Test::BDD::Cucumber::Executor":

       ·   "Test::BDD::Cucumber::Harness::*"

       ·   "Test::BDD::Cucumber::StepContext"

       ·   "Test::BDD::Cucumber::TestBuilderDelegator"

       ·   "Test::BDD::Cucumber::Errors"

       ·   "Test::BDD::Cucumber::Extension"

       Please note that the "Test::BDD::Cucumber::Harness" should not be confused with
       "TAP::Harness" or "Test2::Harness"; this harness is TBC's own and optionally forwards
       events to the "Test::Builder::Test" harness.


       The core of a Cucumber-based test suite are the feature files and the step definitions
       files. By convention, these are saved under "/features/" and "/features/step_definitions/"

       The feature files are encapsulated by the classes in "Test::BDD::Cucumber::Model".

                         one to one
             |                               |
             +-------------------+           |
             | has many          | has a     | has many
             V                   |           V
        TBCM::Scenario           +----->TBCM::Line
             |                            ^  ^
             +----------------------------+  |
             | has many                      |
             V                               |


       We build up a Test::BDD::Cucumber::Executor object, in to which we load the step
       definitions. We then pass this in a Test::BDD::Cucumber::Model::Feature object, along with
       a Test::BDD::Cucumber::Harness object, which controls interaction with the outside world.

       While running step functions, "Test::BDD::Cucumber::Executor" reroutes the flow of test
       events (calls to "ok", "fail", etc) to itself. Based on the collected data, the step
       itself is reported as a success or failure to the test driver.

       Confusing about this situation is that both the channel to report through to the actual
       test driver is an instance of Test::Builder as well as the method used to route the stream
       of test events to itself uses a Test::Builder instance.


       Extensions allow hooking into the execution of the steps, with pre- and post hooks for
       steps, scenarios, features and the entire execution. Extensions can provide additional
       step directories from which steps will be made available. The feature and scenario stashes
       are passed to the extension hooks allowing for a means of communication between the hooks
       and the steps.

       Extensions - when loaded by the pherkin test executor - receive their configuration from
       the pherkin.yaml configuration file, which works similar to the configuration of
       extensions in Behat <>.

       Note: when using extensions in combination with the "TAP::Parser::SourceHandler::Feature"
       plugin for "prove", there is no guarantee that the "pre_execute" and "post_execute" hooks
       execute exactly once or even execute at all.  This is a current limitation to be lifted in
       a future release.


       Peter Sergeant ""


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

perl v5.28.1                                2019-09Test::BDD::Cucumber::Manual::Architecture(3pm)