phpphpunit

PHPUnit best practices to organize tests

I am currently going to start from scratch with the phpunit tests for a project. So I was looking into some projects (like Zend) to see how they are doing things and how they organizing their tests.

Most things are pretty clear, only thing I have some problems with is how to organize the test suites properly. Zend has an AllTests.php from which loads others test suites.
Tough looking at the class it is useing PHPUnit_Framework_TestSuite to create a suite object and then add the other suites to it, but if I look in the PHPUnit docs for organizing tests in PHPUnit versions after 3.4 there is only a description for XML or FileHierarchy. The one using classes to organize the tests was removed.
I haven't found anything that this method is deprecated and projects like Zend are still using it.

But if it is deprecated, how would I be able to organize tests in the same structure with the xml configuration? Executing all tests is no problem, but how would I organize the tests (in the xml) if I only wanted to execute a few tests. Maybe creating several xmls where I only specify a few tests/test suites to be run?

So if I would want to only test module1 and module2 of the application, would I have an extra xml for each and defining test suites only for those modules (classes used by the module) in it. And also one that defines a test suite for all tests?

Or would it be better to use the @group annotation on the specific tests to mark them to be for module1 or module2?

Thanks in advance for pointing me to some best practices.

Solution

  • I'll start of by linking to the manual and then going into what I've seen and heard in the field.

    Organizing phpunit test suites

    Module / Test folder organization in the file system

    My recommended approach is combining the file system with an xml config.

    tests/
 \ unit/
 | - module1
 | - module2
 - integration/
 - functional/

    with a phpunit.xml with a simple:

    <testsuites>
  <testsuite name="My whole project">
    <directory>tests</directory>
  </testsuite>
</testsuites>

    you can split the testsuites if you want to but thats a project to project choice.

    Running phpunit will then execute ALL tests and running phpunit tests/unit/module1 will run all tests of module1.

    Organization of the "unit" folder

    The most common approach here is to mirror your source/ directory structure in your tests/unit/ folder structure.

    You have one TestClass per ProductionClass anyways so it's a good approach in my book.

    In file organization

    It's not going to work anyways if you have more than one test class in one file so avoid that pitfall.

    It just makes writing the test more verbose as you need an additional use statement so I'd say the testClass should go in the same namespace as the production class but that is nothing PHPUnit forces you to do. I've just found it to be easier with no drawbacks.

    Executing only a few tests

    For example phpunit --filter Factory executes all FactoryTests while phpunit tests/unit/logger/ executes everything logging related.

    You can use @group tags for something like issue numbers, stories or something but for "modules" I'd use the folder layout.

    Multiple xml files

    It can be useful to create multiple xml files if you want to have:

    Code coverage for your tests

    As it is related to starting a new project with tests:

    Autoloading and bootstrapping your tests

    You don't need any sort of auto loading for your tests. PHPUnit will take care of that.

    Use the <phpunit bootstrap="file"> attribute to specify your test bootstrap. tests/bootstrap.php is a nice place to put it. There you can set up your applications autoloader and so on (or call your applications bootstrap for that matter).

    Summary

    Sample projects to look at