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.

I'm having the same problem with PHPUnit2-2.2.0beta5 but as the classes have been refactored the code now seems to be in PHPUnit2/Runner/StandardTestSuiteLoader.php D:\htdocs\phlickr\tests>phpunit Api.php PHP Warning: PHPUnit2_Runner_StandardTestSuiteLoader::load(Api.php.php): failed to open stream: No such file or directory in C:\Program Files\php\PEAR\PHPUnit2\Runner\StandardTestSuiteLoader.php on line 44 PHP Warning: PHPUnit2_Runner_StandardTestSuiteLoader::load(): Failed opening 'Api.php.php' for inclusion (include_path='.;C:\Program Files\php\pear;c:\program files\php\includes;D:\htdocs') in C:\Program Files\php\PEAR\PHPUnit2\Runner\StandardTestSuiteLoader.php on line 44 Class Api could not be found in Api.php.php. D:\htdocs\phlickr\tests>phpunit Api Class Api could not be found in Api.php.

D:\htdocs\phlickr\tests>phpunit Api Class Api could not be found in Api.php. Oh, duhh. It can't find the class in the file because the file and class have different names. I'm naming my classes in the PEAR-ish way so Phlickr/Tests/Api.php becomes Phlickr_Tests_Api. D:\htdocs\phlickr\tests>phpunit Phlickr_Tests_Api Api.php PHPUnit 2.2.0beta5 by Sebastian Bergmann. ............. Time: 5.206521 OK (13 tests) I guess I'll put in a RFE for a TestSuiteLoader that figure out a PEAR style class name based on the subdirectories off a specified root.

The current loader is PEAR compatible in the sense that it tries to include Foo/Bar/Barbara.php for Foo_Bar_Barbara. I see no solution to map Barbara.php (when PHPUnit is invoked inside the Foo/Bar directory) to Foo_Bar_Barbara. Maybe you should consider using a TestSuite (see PHPUnit2's own testsuite for a starting point).

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?

"phpunit Foo" works fine for me when Foo.php is in the current directory. But I have "." in my include_path, which is a recommended php.ini setting, IIRC. Does changing line 44 in StandardTestSuiteLoader.php from @include_once . $suiteClassFile; to @include_once './' . $suiteClassFile; solve the problem for you?

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

This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on pear.php.net. In case this was a pear.php.net website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better.

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.

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

Sorry, but your problem does not imply a bug in PEAR itself. For a list of more appropriate places to ask for help using PEAR, please visit http://pear.php.net/support/ as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PEAR. You are trying to use PHPUnit with the CGI SAPI module when you need to use the CLI SAPI module.