Test::BDD::Cucumber::StepContext(3)

NAME
Test::BDD::Cucumber::StepContext - Data made available to step definitions

VERSION
version 0.87

DESCRIPTION
The coderefs in Step Definitions have a single argument passed to them, a "Test::BDD::Cucumber::StepContext" object. This is an attribute-only class, populated by Test::BDD::Cucumber::Executor.

When steps are run normally, C() is set directly before execution to return the context; this allows you to do:

  sub { return C->columns }

instead of:

  sub { my $c = shift; return $c->columns; }

ATTRIBUTES

  columns
If the step-specific data supplied is a table, the this attribute will contain the column names in the order they appeared.

  _data
Step-specific data. Will either be a text string in the case of a """ string, or an arrayref of hashrefs if the step had an associated table.

See the "data" method below.

  stash
A hash of hashes, containing two keys, "feature", "scenario". The stash allows you to persist data across features or scenarios.

The scenario-level stash is also available to steps by calling S(), making the following two lines of code equivalent:

 sub { my $context = shift; my $stash = $context->stash->{'scenario'}; $stash->{'count'} = 1 }
 sub { S->{'count'} = 1 }

  feature

  scenario

  step
Links to the Test::BDD::Cucumber::Model::Feature, Test::BDD::Cucumber::Model::Scenario, and Test::BDD::Cucumber::Model::Step objects respectively.

  verb
The lower-cased verb a Step Definition was called with.

  text
The text of the step, minus the verb. Placeholders will have already been multiplied out at this point.

  harness
The Test::BDD::Cucumber::Harness harness being used by the executor.

  executor
Weak reference to the Test::BDD::Cucumber::Executor being used - this allows for step redispatch.

  matches
Any matches caught by the Step Definition's regex. These are also available as $1, $2 etc as appropriate.

  is_hook
The harness processing the output can decide whether to shop information for this step which is actually an internal hook, i.e. a Before or After step

  parent
If a step redispatches to another step, the child step will have a link back to its parent step here; otherwise undef. See "Redispatching".

METHODS

  background
Boolean for "is this step being run as part of the background section?". Currently implemented by asking the linked Scenario object...

  data
See the "_data" attribute above.

Calling this method will return either the """ string, or a possibly Transform-ed set of table data.

  matches
See the "_matches" attribute above.

Call this method will return the possibly Transform-ed matches .

  transform
Used internally to transform data and placeholders, but it can also be called from within your Given/When/Then code.

Redispatching
Sometimes you want to call one step from another step. You can do this via the StepContext, using the dispatch() method. For example:

  Given qr/I have entered (\d+)/, sub {
        C->dispatch( 'Given', "I have pressed $1");
        C_>dispatch( 'Given', "I have passed-in data", C->data );
        C->dispatch( 'Given', "I have pressed enter", { some => 'data' } );
  };

You redispatch step will have its own, new step context with almost everything copied from the parent step context. However, specifically not copied are: "columns", "data", the "step" object, and of course the "verb" and the "text".

If you want to pass data to your child step, you should IDEALLY do it via the text of the step itself, or failing that, through the scenario-level stash. Otherwise it'd make more sense just to be calling some subroutine... But you can pass in a third argument - a hashref which will be used as "data". The data in that third argument can be one of:

•   a string

    This scenario corresponds with having a """ ... """ string argument to the step. It's passed to the child step verbatim.

•   a hash reference (deprecated)

    This scenario corresponds with the third example above and has been supported historically. There is no good reason to use this type of argument passing, because there is no way for a feature to pass data to the step. When you need to use this scenario, please consider implementing a separate subroutine instead.

•   a reference to an array of hashes

    This scenario corresponsds with a data table argument to the step. The names of the columns are taken from the first hash in the array (the first row in the data table).

    No transformations are applied to the table passed in to prevent duplicate transformations being applied.

The value of the third argument will be used as the "C->data" value for the "StepContext" of the child step. All values passed in, will be passed to the child without applying "Transform" declarations. That way, double transformation is prevented.

If the step you dispatch to doesn't pass for any reason (can't be found, dies, fails, whatever), it'll throw an exception. This will get caught by the parent step, which will then fail, and show debugging output.

You must use the English names for the step verb, because we have no access to the parser. Also, remember to quote them as if you're in a step file, there may be a subroutine defined with the same name.

  dispatch
    C->dispatch( 'Then', "the page has loaded successfully");

See the paragraphs immediately above this

AUTHOR
Peter Sergeant "pete@clueball.com"

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