tags:

views:

43

answers:

2

From what I've read, it seems like I should be able to set up a folder, e.g. tests/ , put a few files in it with unit test classes, and then run phpunit on that file and have it find and run the tests.

For whatever reason, in my installation (on OS X), it thinks the folder tests/ is a file, or so it would seem:

$ ls tests
test1.php test2.php
$ phpunit tests/test1.php
PHPUnit 3.5.3 by Sebastian Bergmann.

F

Time: 0 seconds, Memory: 5.00Mb

There was 1 failure:

1) FailingTest::testFail
Your test successfully failed!

/Users/****/tmp/tests/test1.php:4

FAILURES!
Tests: 1, Assertions: 0, Failures: 1.
$ phpunit tests/test2.php
PHPUnit 3.5.3 by Sebastian Bergmann.

.

Time: 0 seconds, Memory: 5.00Mb

OK (1 test, 1 assertion)
$ phpunit tests
PHP Fatal error:  Uncaught exception 'PHPUnit_Framework_Exception' with message 'Neither "tests.php" nor "tests.php" could be opened.' in /usr/local/PEAR/PHPUnit/Util/Skeleton/Test.php:102
Stack trace:
#0 /usr/local/PEAR/PHPUnit/TextUI/Command.php(157): PHPUnit_Util_Skeleton_Test->__construct('tests', '')
#1 /usr/local/PEAR/PHPUnit/TextUI/Command.php(129): PHPUnit_TextUI_Command->run(Array, true)
#2 /usr/local/bin/phpunit(53): PHPUnit_TextUI_Command::main()
#3 {main}
  thrown in /usr/local/PEAR/PHPUnit/Util/Skeleton/Test.php on line 102

Fatal error: Uncaught exception 'PHPUnit_Framework_Exception' with message 'Neither "tests.php" nor "tests.php" could be opened.' in /usr/local/PEAR/PHPUnit/Util/Skeleton/Test.php:102
Stack trace:
#0 /usr/local/PEAR/PHPUnit/TextUI/Command.php(157): PHPUnit_Util_Skeleton_Test->__construct('tests', '')
#1 /usr/local/PEAR/PHPUnit/TextUI/Command.php(129): PHPUnit_TextUI_Command->run(Array, true)
#2 /usr/local/bin/phpunit(53): PHPUnit_TextUI_Command::main()
#3 {main}
  thrown in /usr/local/PEAR/PHPUnit/Util/Skeleton/Test.php on line 102

I have what I hope is a fairly standard installation of phpunit via PEAR, following these instructions http://www.newmediacampaigns.com/page/install-pear-phpunit-xdebug-on-macosx-snow-leopard, on OS X Snow Leopard.

$ pear version
PEAR Version: 1.9.1
PHP Version: 5.3.2
Zend Engine Version: 2.3.0
Running on: **** 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386
$ phpunit --version
PHPUnit 3.5.3 by Sebastian Bergmann.

I'm hoping someone else out there ran into this issue and it's just a simple fix, or else I'm just doing something wrong?

+2  A: 

Annoying little quirk, but I figured it out.

At least with the default configuration, test files have to end with "Test.php", eg. fooTest.php, or they are not found by the test runner.

jsdalton
A: 

It is not a bug, it is a feature.

You have a directory full of .php files, in your case they all contain testcases.

But as your testsuite grows, you will likely want to have other php files inside tests directory, files that do not contains tests, that exist solely to support tests. Those files should never be executed by PHPUnit itself.

This is a very common scenario.

So how would PHPUnit know which files it needs to run and which ones not? Checking the file name suffix is one option for doing it - by default PHPUnit considers everything with name ending as Test.php as being a test and ignores everything else.

You can change that behaviour if you really want to - by creating a file named phpunit.xml in your tests directory with the following content

<?xml version="1.0" encoding="utf-8" ?>
<phpunit>
<testsuite name='Name your suite'>
    <directory suffix='.php'>./</directory>
</testsuite>
</phpunit>

Once you have done that, PHPUnit will run all files with '.php' at the end of the file name (in this context file extension is considered to be part of the file name)

But it really is better to get used to the convention and name your tests accordingly.

Anti Veeranna
Agreed. I don't think the behavior of phpunit was incorrect, it's just that this requirement was not made explicit in the documentation anywhere, and thus I got sucked down a rabbit hole trying to figure this out for about an hour. I filed a ticket though and the maintainer has already committed a patch to the documentation which clarifies it.
jsdalton
Great, documentation improvements are always useful :)
Anti Veeranna