| Package home | Report new bug | New search | Development Roadmap | Status: Open | Feedback | All | Closed Since Version 2.3.6 |
| Bug #3562 | PHPUnit does not find test classes to include | ||
|---|---|---|---|
| Submitted: | 2005-02-23 14:31 UTC | ||
| From: | info at e-novative dot de | Assigned: | |
| Status: | Bogus | Package: | PHPUnit2 |
| PHP Version: | 5.0.3 | OS: | Windows XP |
| Roadmaps: | (Not assigned) | ||
[2005-02-23 14:31 UTC] info at e-novative dot de
Description:
------------
I am not sure if this is a bug or if just I'm doing something wrong, but:
When I run "phpunit xxx" at the command line, I get an error saying that PHPUnit cannot find the class xxx (xxx.php in the current directory, that is) in line 44 of TestSuiteLoader.php. The test class xxx.php is in the working directory, however. When I modify line 44 in the file PHPUnit2/Runner/TestSuiteLoader.php to
include_once getcwd() . '/' . $suiteClassFile;
the test classes are loaded correctly. This leads me to suspect that somewhere on the way through PHPUnit, possibly the working directory is changed?
When I add the working directory to the PHP include path in php.ini, the test classes are found and loaded correctly without the above patch. Of course it is not desirable to add the working directory to the include path every time you want to run unit tests.
Comments
[2005-02-25 06:33 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2005-02-25 06:59 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2005-02-25 07:09 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2005-02-25 07:20 UTC] info at e-novative dot de
So how about my original problem, which is somewhat different from drewish's: PHPUnit (2.2.0-beta5) does not find classes in the working directory unless that directory is in PHP's include path. There is no PEAR naming issue involved here, it's just that the classes are not found, but when I make the include statement in TestSuiteLoader.php use an absolute path (as described in my original post), the classes are found.
Am I doing something wrong here or is that an issue with PHPUnit?
[2005-02-25 07:33 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2005-02-25 08:00 UTC] info at e-novative dot de
Sebastian,
thanks for the hint. Adding './' works (as did adding getcwd()), and adding . to the PHP include path does the same job. We'll update our WAMP accordingly.
A small note in the manual (hmmm ... which manual?) might be helpful to those who are equally stupid as I am, or maybe it is even safe to apply your fix to PHPUnit.
Thanks!
Steve
[2005-02-25 09:27 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2005-03-06 16:25 UTC] someone at somewhere dot com
I had the "could not be found in" error with PHPUnit 2.1.6 and 2.2.0beta6. In my situation it helped when I added -C flag to PHP in the phpunit script as:
#!/usr/bin/php -C
That tells PHP not to change it's current working directory and I can run tests now.
[2005-06-29 20:49 UTC] lukfugl at gmail dot com
Similar to the comment "[2005-03-06 16:25 UTC] someone at somewhere dot com", I added the -C to the shebang in /usr/local/bin/phpunit as a workaround to this problem. In my case, I dug all the way into StandardTestLoader#load and printed out the working directory -- it came out as /usr/local/bin/ instead of the directory from which I had run phpunit. Due to the changed CWD, even having '.' in the php include path didn't help since '.' referred to /usr/local/bin.
The recurrence of this bug only working for some users may be due to different php configurations, some of which may have the effect of -C enabled by default, where others (like mine) don't. Adding the -C flag to phpunit in the distribution should be a suitable fix.
My version information:
$ php --version
PHP 5.0.4 (cgi-fcgi) (built: Apr 26 2005 13:26:11)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies
$ phpunit --version
Content-type: text/html
X-Powered-By: PHP/5.0.4
PHPUnit 2.2.1 by Sebastian Bergmann.
Jacob Fugal
[2005-06-30 05:44 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!