Class: behat_generator_base  - X-Ref

Class to quickly create Behat test data using component data generators.

There is a subclass of class for each component that wants to be able to
generate entities using the Behat step
Given the following "entity types" exist:
| test | data |

For core entities, the entity type is like "courses" or "users" and
generating those is handled by behat_core_generator. For other components
the entity type is like "mod_quiz > User override" and that is handled by
behat_mod_quiz_generator defined in mod/quiz/tests/generator/behat_mod_quiz_generator.php.

The types of entities that can be generated are described by the array returned
by the {@link get_generateable_entities()} method. The list in
{@link behat_core_generator} is a good (if complex) example.

How things work is best explained with a few examples. All this is implemented
in the {@link generate_items()} method below, if you want to see every detail of
how it works.

Simple example from behat_core_generator:
'users' => [
'datagenerator' => 'user',
'required' => ['username'],
],
The steps performed are:

1. 'datagenerator' => 'user' means that the word used in the method names below is 'user'.

2. Because 'required' is present, check the supplied data exists 'username' column is present
in the supplied data table and if not display an error.

3. Then for each row in the table as an array $elementdata (array keys are column names)
and process it as follows

4. (Not used in this example.)

5. If the method 'preprocess_user' exists, then call it to update $elementdata.
(It does, in this case it sets the password to the username, if password was not given.)

We then do one of 4 things:

6a. If there is a method 'process_user' we call it. (It doesn't for user,
but there are other examples like process_enrol_user() in behat_core_generator.)

6b. (Not used in this example.)

6c. Else, if testing_data_generator::create_user exists, we call it with $elementdata. (it does.)

6d. If none of these three things work. an error is thrown.

To understand the missing steps above, consider the example from behat_mod_quiz_generator:
'group override' => [
'datagenerator' => 'override',
'required' => ['quiz', 'group'],
'switchids' => ['quiz' => 'quiz', 'group' => 'groupid'],
],
Processing is as above, except that:

1. Note 'datagenerator' is 'override' (not group_override). 'user override' maps to the
same datagenerator. This works fine.

4. Because 'switchids' is present, human-readable data in the table gets converted to ids.
They array key 'group' refers to a column which may be present in the table (it will be
here because it is required, but it does not have to be in general). If that column
is present and contains a value, then the method matching name like get_group_id() is
called with the value from that column in the data table. You must implement this
method. You can see several examples of this sort of method below.

If that method returns a group id, then $elementdata['group'] is unset and
$elementdata['groupid'] is set to the result of the get_group_id() call. 'groupid' here
because of the definition is 'switchids' => [..., 'group' => 'groupid'].
If get_group_id() cannot find the group, it should throw a helpful exception.

Similarly, 'quiz' (the quiz name) is looked up with a call to get_quiz_id(). Here, the
new array key set matches the old one removed. This is fine.

6b. We are in a plugin, so before checking whether testing_data_generator::create_override
exists we first check whether mod_quiz_generator::create_override() exists. It does,
and this is what gets called.

This second example shows why the get_..._id methods for core entities are in this base
class, not in behat_core_generator. Plugins may need to look up the ids of
core entities.

behat_core_generator is defined in lib/behat/classes/behat_core_generator.php
and for components, behat_..._generator is defined in tests/generator/behat_..._generator.php
inside the plugin. For example behat_mod_quiz_generator is defined in
mod/quiz/tests/generator/behat_mod_quiz_generator.php.