PHPUnit не может найти тестовый класс, если он загружается автоматически/вручную в начальной загрузке

Я столкнулся с необычной проблемой загрузки классов в PHPUnit, первоначально сталкивавшейся с 4.3.5, а теперь и с последней версией 4.4.2 (последняя стабильная).

У меня есть загрузочный файл, который загружается через phpunit.xml автоматически, включая автозагрузчик Composer по умолчанию, а также мой собственный автозагрузчик. Это прекрасно работает, как есть. Однако я обнаружил, что если я загружаю тестовый класс в загрузчик, то PHPUnit не может правильно разрешить имя класса и поэтому не загружается.

Я получаю эту ошибку:

Не удалось найти класс «test/unit/tests/UpdateAllTest» в «/full/project/path/webapp/test/unit/tests/UpdateAllTest.php».

(Моя цель в том, чтобы сослаться на тестовый класс в начальной загрузке, состоит в том, чтобы добавить метод сборки базы данных в каждый из них, сохраняя его с тестовым файлом, к которому он относится. Я планирую сделать это в начальной загрузке, а не в методе setUp(), поскольку Я хочу, чтобы он выполнялся один раз для всех тестов, а не один раз для каждого метода тестирования).

Я провел небольшую отладку внутри самого PHPUnit (в частности, PHPUnit_Runner_StandardTestSuiteLoader::load) и обнаружил, что имя класса неверно указано как путь, а не как имя класса в пространстве имен. Вот соответствующий пункт:

    if (class_exists($suiteClassName, false)) {
        $class = new ReflectionClass($suiteClassName);

        if ($class->getFileName() == realpath($suiteClassFile)) {
            return $class;
        }
    }

Значение $suiteClassName равно test/unit/tests/UpdateAllTest, что явно не является пространством имен — оно должно быть Awooga\Testing\Unit\UpdateAllTest, что обычно обрабатывается пользовательским сопоставлением в моем автозагрузчике.

Я не думаю, что делаю что-то особенно необычное с PHPUnit, и поэтому считаю маловероятным, что это ошибка, с которой до сих пор никто не сталкивался. В этих обстоятельствах мне, возможно, нужно объявить пространства имен классов в phpunit.xml или что-то необычное в этом роде? Вот и хватайся за соломинку!

Любые мысли о том, что может быть причиной этой, казалось бы, тривиальной проблемы, будут оценены. А пока я просто перенесу эти методы настройки в другой файл/класс - не идеально, но и не конец света. У меня PHP 5.5.x и Ubuntu 12.04.


person halfer    schedule 19.01.2015    source источник
comment
Является ли класс в вашем файле Bootstrap пространством имен?   -  person Schleis    schedule 19.01.2015
comment
@Schleis, спасибо: класс есть, и он там нормально загружается автоматически. Только после этого PHPUnit не понимает, что он уже загружен, и не создает его экземпляр.   -  person halfer    schedule 19.01.2015
comment
Я не могу сказать по вашему вопросу, но уверены ли вы, что имеете в виду класс с правильным пространством имен, когда он не найден?   -  person Schleis    schedule 20.01.2015
comment
Да, я уверен, @Schleis. Его не находит PHPUnit, а не PHP — если посмотреть на ошибку, то у нее нет номера строки, и она бы подошла, если бы это было обычное необработанное исключение из PHP. Исключение, вызывающее это, можно найти в исходном коде PHPUnit.   -  person halfer    schedule 20.01.2015


Ответы (2)


Я не исправил это, но мои методы сборки теперь настолько длинные, что в любом случае имеет смысл отображать их в разных классах. У меня есть соглашение об именах, поэтому тест *Test.php имеет соответствующий класс сборки *Build.php.

Я использую систему начальной загрузки PHPUnit для сканирования классов сборки и автоматического вызова статического build() внутри.

person halfer    schedule 01.02.2015

Возможно, вы также сталкиваетесь с этой проблемой.

Наличие пути в качестве параметра является нормальным поведением на этом этапе, проверка ниже в PHPUnit_Runner_StandardTestSuiteLoader::load вызывает это запутанное сообщение об ошибке.

person Ben    schedule 20.02.2015
comment
Спасибо Бен, звучит очень похоже. Пожалуйста, дайте мне знать, как вы справляетесь с этим отчетом об ошибке. Я тоже поискал в трекере, ничего не нашел. Я предположил, что, поскольку это кажется такой очевидной проблемой, я просто делаю что-то не так! - person halfer; 20.02.2015
comment
Пожалуйста. Постараюсь вспомнить, но думаю, что это не скоро исправят. - person Ben; 23.02.2015