1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
package Test::BDD::Cucumber::Manual::Architecture;
=head1 NAME
Test::BDD::Cucumber::Manual::Architecture - Structural Overview
=head1 VERSION
version 0.75
=head1 INTRODUCTION
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
C<Test::BDD::Cucumber::Executor> which links the two groups together; building on
the steps to execute the features.
In the first group are C<Test::BDD::Cucumber::StepFile> and
C<Test::BDD::Cucumber::Loader>. The second group is bigger and is comprised of
=over 4
=item * C<Test::BDD::Cucumber::Parser>
=item * C<Test::BDD::Cucumber::Model::*>
=back
The third group holds - next to C<Test::BDD::Cucumber::Executor>:
=over 4
=item * C<Test::BDD::Cucumber::Harness::*>
=item * C<Test::BDD::Cucumber::StepContext>
=item * C<Test::BDD::Cucumber::Errors>
=item * C<Test::BDD::Cucumber::Extension>
=back
Please note that the C<Test::BDD::Cucumber::Harness> should not be confused
with C<TAP::Harness> or C<Test2::Harness>; this harness is TBC's own and
optionally forwards events to the C<Test::Builder::Test> harness.
=head1 MODELS
The core of a Cucumber-based test suite are the feature files and the step
definitions files. By convention, these are saved under C</features/> and
C</features/step_definitions/> respectively.
The feature files are encapsulated by the classes in
C<Test::BDD::Cucumber::Model>.
one to one
TBCM::Feature<----------------->TBCM::Document
| |
+-------------------+ |
| has many | has a | has many
V | V
TBCM::Scenario +----->TBCM::Line
| ^ ^
+----------------------------+ |
| has many |
V |
TBCM::Step---------------------------+
=head1 EXECUTOR
We build up a L<Test::BDD::Cucumber::Executor> object, in to which we load the
step definitions. We then pass this in a L<Test::BDD::Cucumber::Model::Feature>
object, along with a L<Test::BDD::Cucumber::Harness> object, which
controls interaction with the outside world.
=head2 Test::Builder
While running step functions, C<Test::BDD::Cucumber::Executor> reroutes
the flow of test events (calls to C<ok>, C<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.
=head1 EXTENSION
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.
Additionally, as of I<0.60>, it's possible to define meta data for a step
upon step definition like this example:
Given qr/a step with meta data/ => { meta => 'data' }, sub { };
This allows step function authors to communicate with extensions, because
extensions receive this meta data in their C<pre_step> callback:
sub pre_step {
my ($stepdef, $step_context) = @_;
my ($verb, $metadata, $stepfn) = @$stepdef;
die 'All steps should have meta -> data'
unless $metadata->{meta} eq 'data';
}
Extensions - when loaded by the pherkin test executor - receive their
configuration from the pherkin.yaml configuration file, which works
similar to L<the configuration of extensions in
Behat|http://docs.behat.org/en/v2.5/guides/7.config.html#extensions>.
Note: when using extensions in combination with the
C<TAP::Parser::SourceHandler::Feature> plugin for C<prove>, there is no
guarantee that the C<pre_execute> and C<post_execute> hooks execute
exactly once or even execute at all.
This is a current limitation to be lifted in a future release.
=head1 AUTHOR
Peter Sergeant C<pete@clueball.com>
=head1 LICENSE
Copyright 2019-2020, Erik Huelsmann
Copyright 2011-2019, Peter Sergeant; Licensed under the same terms as Perl
=cut
1;
|
