Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
In FormElementTestCase::testOptions()
(file: modules/simpletest/tests/form.test), there's the following check:
// Verify that custom #description properties are output.
foreach (array('checkboxes', 'radios') as $type) {
$elements = $this->xpath('//input[@name=:name]/following-sibling::div[@class=:class]', array(
':name' => $type . '[foo]',
':class' => 'description',
));
$this->assertTrue(count($elements), t('Custom %type option description found.', array(
'%type' => $type,
)));
}
This should cause one test failure with the radios
element: radios[foo] is not a valid name for radio elements. However, it seems my server is the only one that actually catches this failure. The HEAD tester doesn't, and checking with sun in IRC, his testing environment doesn't either.
Comment | File | Size | Author |
---|---|---|---|
#2 | 977184-testoptions.patch | 973 bytes | Stevel |
Comments
Comment #1
Mark TrappAh, it turns out this is the root cause: #933856: xpath() return values are inconsistent. The fix in there should only cause this test to fail for everyone instead of people with certain versions of libxml. For the record, it fails with the following environment:
PHP 5.3.3
Libxml 2.7.3
Comment #2
Stevel CreditAttribution: Stevel commentedNo idea why it's not failing everywhere, but in my environment, the test fails as well.
PostgreSQL 9
PHP 5.3.3
libxml 2.7.7
Comment #3
Mark TrappWorks as advertised: patch applies, tests pass. Hopefully #933856: xpath() return values are inconsistent will expose any other falsely-passing tests.
Comment #4
webchickNice sleuthing!
Committed to HEAD. Thanks!
Comment #5
sunmmm, neither previous HEAD nor current HEAD are correct.
For #type radios, :name needs to be just $type (current), but
for #type checkboxes, :name needs to be $type . [foo] (previous)
Effectively, the wrapping foreach is wrong and both types need to be tested separately.
Comment #6
Stevel CreditAttribution: Stevel commentedCurrent HEAD does not search for the name attribute but uses the id attribute instead.
What is wrong with searching for the id edit-$type-foo? This is valid for both checkboxes and radios, and seems the only way to find the relevant radio element anyway.
Comment #7
Mark TrappCurrent HEAD is correct: if the
name
attribute were just "radios", it'd match on both radio groups present on the page instead of the one with the custom description (see markup below). Using id instead of name allows the test to target just the radio element with the custom description, as it does with the checkboxes.Comment #8
sunok, could have used an inline code comment, but I understand how it's able to work now, thanks.