PHPUnit tearDownAfterClass called too soon with ZendStudio

Question

I have a very strange problem with PHPUnit in Zend Studio. I have a unit test with two current test methods. I'm using setUpBeforeClass() and tearDownAfterClass() to initialise a database connection and to destroy it. The problem I have is that tearDownAfterClass() is called after the first test method. When setUp() is called after that there's an error due to the fact that no database connection then exists. I can't work out for the life of me what's going on. I've confirmed the problem by stepping through the test using ZendDebugger. I'm also using the version of PHPUnit embedded in ZendStudio. Here's the test code:

    <?php
require_once '../Code\includes\classes\datamapper\basedatamapper.class.php';
require_once '../Code\includes\classes\datamapper\userdatamapper.php';
require_once '../Code\includes\classes\users\user.class.php';
require_once 'PHPUnit\Framework\TestCase.php';

use DataMapper\UserDataMapper, Users\User;

/**
 * UserDataMapper test case.
 */
class UserDataMapperTest extends PHPUnit_Framework_TestCase {
    /**
     * @var UserDataMapper
     */
    private $UserDataMapper;

    protected static $db;

    static public function setUpBeforeClass() {
        self::$db = new PDO('mysql:host=localhost;dbname=cfoundtest', 'root', 'Andrea30Cook');
        self::$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    }
    /**
     * Prepares the environment before running a test.
     */
    protected function setUp() {
        parent::setUp();
        $this->UserDataMapper = new UserDataMapper(self::$db, simplexml_load_file(dirname(__DIR__) . '/Code/mapping/userMapping.xml')); 
    }   
    /**
     * @dataProvider UserGenerator
     */
    public function testSaveNewUser($firstname, $lastname, $password, $username, $userType, $email) {
        $user = new User();
        $user->setFirstname($firstname)
                ->setLastname($lastname)
                ->setPassword($password)
                ->setUsername($username)
                ->setUserType($userType)
                ->setEmail($email);
        $this->assertTrue($this->UserDataMapper->save($user));
        $this->assertType('int', $user->getId());
        $this->assertType('string', $user->getConfString());
        $this->assertSame(40, strlen($user->getConfString()));
    }
    /**
     * @dataProvider UserGenerator
     */
    public function testAddingUserException($firstname, $lastname, $password, $username, $userType, $email) {
        $user = new User();
        $user->setFirstname($firstname)
                ->setLastname($lastname)
                ->setPassword($password)
                ->setUsername($username)
                ->setUserType($userType)
                ->setEmail($email);
        $this->setExpectedException('InvalidArgumentException', sprintf('Username "%s" is already taken in DataMapper\UserDataMapper::insert', $user->getUsername()));
        $this->UserDataMapper->save($user);
    }

    public static function UserGenerator() {
        return array(
            array(
                'Foo',
                'Bar',
                'Secret Test',
                'Foobar',
                'Authorizer',
                'example@example.com'
            ),
            array(
                'Fred',
                'Flintstone',
                'Secret Test',
                'BarBaz',
                'Admin',
                'example2@example.com'
            )
        );
    }
    /**
     * Cleans up the environment after running a test.
     */
    protected function tearDown() {
        // TODO Auto-generated UserDataMapperTest::tearDown()


        $this->UserDataMapper = null;

        parent::tearDown();
    }

    static public function tearDownAfterClass() {
        self::$db->exec('DELETE FROM failedlogins');
        self::$db->exec('DELETE FROM users');
        self::$db = NULL;
    }
}

Answer 1

OK, I think this is an issue with either ZendStudio or the version of PHPUnit bundled with it. The test runs fine via a PEAR installed PHPUnit 3.5 on the command line. I've refactored the test to hard code in the test data instead of using a data provider (I know, not ideal at all) and that's fixed things for the time being.