I tried the latest HEAD version of Drupal and the latest HEAD version of Simpletest and when I get to the Simpletest screen, the list of tests to run is empty. I backed up and did a fresh install of only core and Simpletest and had the same problem. Then I backed through the cvs versions of Simpletest until I get to one that works right and I had to go back to Jan 9. The next few versions had a fatal error, and then after that the module loads but the test page is empty.

After talking to corsix in IRC, who said he had no problem with the HEAD version, and we figured out that we were using different versions of PHP. I switched from PHP 4 (where the problem exists) to PHP 5 (where everything works fine).

Not sure what is broken in PHP 4, but something is.

Comments

Rok Žlender’s picture

Rok Žlender commented

OK problem found. Method is_subclass_of in PHP4 does NOT accept first param as string and that is exactly what we do in line 64 in drupal_unit_tests.php. Solution would be to create an instance of every one of test classes and then check is_subclass_of. Is it worth it? Are there many users of PHP4 that would like to use this? My bet is on NO, but if there are strong arguments I can be convinced.

karens’s picture

karens commented

I agree that people who would use this are probably using PHP5, I run PHP 4 periodically to test that my code works under PHP 4 and that's how I found this.

The one reason to get it working under PHP 4 is if you want to use simpletest to be sure that your code works right in PHP 4, which would still be a legitimate use case, at least until Drupal 7 when PHP 4 is no longer supported. I have simpletest tests that are supposed to run in PHP 4 in the Date module to be sure the PHP 4 versions of that code work right, since PHP 4 date handling works completely differently than PHP 5 date handling.

karens’s picture

karens commented
Title: No tests are available » Simpletest unusable in PHP4

Renaming for clarity.

beeradb’s picture

beeradb commented

had the same issue in http://drupal.org/node/212769

I'll have to see if I can recreate the problem again, but both of my dev environments were php4, both the one which worked, and the one which did not, maybe it's a PHP configuration setting? if I get some time i'll see if I can recreate the problem, if so i'll post the output from each environments php.ini file. Hopefully that will give us some clues about what's going on, and even if we don't fix it perhaps let people know how/why the issue exists.

just adding that piece to the puzzle.

-brad

boombatower’s picture

boombatower commented
Status: Active » Closed (won't fix)

Since this doesn't seem to be a major concern due to the fact that the errors occur sporadically on test PHP4 environments there doesn't seem to be any compelling reason to spend time creating the workaround.

Especially with the concentration being placed on full test coverage of 7.x.