Skip to content

Conversation

@mpdude
Copy link

@mpdude mpdude commented Nov 12, 2025

It is not easily possible to use the I fill the following step definition with a table to fill forms that include checkboxes: Since minkphp/driver-testsuite#102, downstream drivers (like https://gitlab.com/behat-chrome/chrome-mink-driver/-/issues/169) have started to throw when checkboxes are to be filled with non-boolean values.

This PR suggests to detect that case and perform convenient type conversion.

If there is a better place or more general mechanism to do such conversions, please advise.

@codecov
Copy link

codecov bot commented Nov 12, 2025

Codecov Report

❌ Patch coverage is 50.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 98.46%. Comparing base (916471d) to head (1980083).

Files with missing lines Patch % Lines
src/Element/TraversableElement.php 50.00% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##             master     #876      +/-   ##
============================================
- Coverage     98.72%   98.46%   -0.27%     
- Complexity      389      391       +2     
============================================
  Files            24       24              
  Lines          1022      910     -112     
============================================
- Hits           1009      896     -113     
- Misses           13       14       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@aik099
Copy link
Member

aik099 commented Nov 13, 2025

Interesting problem:

  • the drivers expect the setValue call to have a boolean argument when operating on a checkbox (or an exception is thrown)
  • the \Behat\Mink\Element\TraversableElement::fillField method (used by MinkExtension) doesn't know the operated field type (checkbox or not)
  • the I fill in the following step of MinkExtension isn't able to detect, from provided data, whatever it's filling a regular input or checkbox

I think that we need to improve the MinkExtension part so that it can determine what type of data being set and use the \Behat\Mink\Element\TraversableElement::checkField instead of a \Behat\Mink\Element\TraversableElement::fillField.

But I'm open to suggestions.

@aik099
Copy link
Member

aik099 commented Nov 13, 2025

@mpdude , could you use 2 steps to fill the form both used in the same Gherkin file scenario:

  • the table-based one I fill the following for the non-checkbox/non-radio button fields
  • the I check "..." for checkboxes

?

@stof
Copy link
Member

stof commented Nov 13, 2025

To me, this indeed looks like something that should be implemented in friends-of-behat/mink-extension if it wants to provide a Gherkin step that supports different kind of fields in the same API, instead of adding such magic in the TraversableElement of Mink (while TraversableElement already has checkField which is dedicated to checkboxes).

For no, I'm voting -1 on this PR.

@mpdude
Copy link
Author

mpdude commented Nov 13, 2025

@aik099 generally probably yes, although it may make scenarios a little less fluent to read.

In my particular case, however, I tried that already and failed. I will have to double check, but it may have to do with the structure of the form where the checkbox fields are all named something[] and so there were no unique xpath expressions to match.

I am fine with closing this one here, it was just a quick shot at the first spot that seemed possible.

Is my understanding correct that since MinkExtension does not know anything about the type of the underlying field, all hints need to come from userland (Gherkin), for example with a special markup or notation in the I fill the following step?

@aik099
Copy link
Member

aik099 commented Nov 14, 2025

Is my understanding correct that since MinkExtension does not know anything about the type of the underlying field, all hints need to come from userland (Gherkin), for example with a special markup or notation in the I fill the following step?

Yes.

@mpdude mpdude closed this Nov 14, 2025
@mpdude mpdude deleted the patch-1 branch November 14, 2025 16:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants