From https://tracker.moodle.org/browse/MDL-43713?focusedCommentId=265152&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-265152 discussion.

We should normalize all field values getters and setters and update .feature files if necessary, what it makes sense is to only use the behat_form_field**(set|get)_value() methods

In general we have multiple choices:

• Provide a generic getter and setter
• Provide a generic getter and setter + specific getters and setters
• Provide only specific-field getters and setters

IMO the best option will be a generic one (adding to the multi-field getter and setter) but I'm not sure it will be always possible or will restrict us more than help us.

• Setters

• • Multi-field: I fill the moodle form with: delegates to the form_fields, which is good so no need to do anything else
  • Individual field:
    • Texts:
      • I've run:

        find . -name *.feature | xargs grep " I fill " | grep -v "fill the moodle form" | grep -v "fill the form"

        find . -name behat_*.php | xargs grep " I fill " | grep -v "fill the moodle form" | grep -v "fill the form"

• • • • All the uses of I fill in "ASD" with "ASD" are filling text fields, so I think that we should change the step description to let the users know that it is only inteded to be used to fill text-based fields. If we switch it to (get|set)_value() the behaviour will be the same as will default to behat_form_field. Another option would be to have a I fill in "ASD" with "ASD" text only for text-based fields and a new generic I fill in "ASD" with "ASD" checkboxes or radios don't expect a second argument and may lead to confusion, but in I fill the moodle form with: we solve it passing 0 or 1 as checked/unchecked the generic one can have the same behaviour than the multi I fill the moodle form with: but then the generic one or the specific ones would be rendundant

• • • Selects. Are already using behat_form_select
    • Checkboxes. Will sounds vage, I know but I remember to have trouble here, that's why both have a different implementation
    • Radios. Similar to checkboxes, but as we are not using them extensively it would not be a problem to move to behat_form_field

• Getters

• • Multi-field: We need a multiple one, like I fill the moodle form with:. We can do the same we do in I fill the moodle form with: and pass 0 or 1 to checkboxes and radios, something like the following fields should match the following values: and a cool 2 columns TableNode below.

• • Individual field: Here I doubt whether we have a specialized checker for all of the field types
    • behat_forms::the_field_should_match_value() is the generic one which does it's job and is widely used
    • About specific ones
      • Checkboxes. There are a couple of step definitions (checked and unchecked) that are only used in the feature where we check that the step definitions works as expected, so we can perfectly get rid of it
      • Selects: MDL-43713 introduces new steps here

IMO to normalize the situation we could:

1. Seems easy to deprecate the checkboxes one and fix the generic one to work with all fields, here we may find the same problems we will face in #2 below
2. After #1 we can estimate if it is better to have a single step definition for setters of multiple ones