Комментарии 7
Было бы неплохо упомянуть в статье о dataProvider-ах. Пример из вашей статьи:
$this->assertEquals('hello-world', $blog->slugify('Hello World'));
$this->assertEquals('a day with symfony2', $blog->slugify('A Day With Symfony2'));

Код выше упростится как для чтения, так и для поддержки, если использовать провайдеры данных. Особенно, когда вариантов входных данных много.
Для запуска тестов в Symfony2 вам нужно установить PHPUnit 5.4 (требуется PHP 5.6)Вполне подойдет и PHPUnit 4.x (PHP 5.3+)
В нашем проекте Symfony2 этот файл находится app/phpunit.xml.dist.
Так как этот файл с суффиксом .dist, вам необходимо скопировать его содержимое в файл с именем app/phpunit.xml.PHPUnit поддерживает файлы конфигурации с суффиксом .dist. Если явно не указан файл конфигурации (а только директория, как в случае с -c app) или вовсе не указана опция -c и файл phpunit.xml присутствует (например, для конфигурации с code coverage), будет использован он, если же его нет, будет использован phpunit.xml.dist (если существует).
Пруф: If phpunit.xml or phpunit.xml.dist (in that order) exist in the current working directory and --configuration is not used, the configuration will be automatically read from that file.
Для запуска тестов в Symfony2 вам нужно установить PHPUnit 5.4 (требуется PHP 5.6)
Вполне подойдет и PHPUnit 4.x (PHP 5.3+)
В нашем проекте Symfony2 этот файл находится app/phpunit.xml.dist.
Так как этот файл с суффиксом .dist, вам необходимо скопировать его содержимое в файл с именем app/phpunit.xml.
PHPUnit поддерживает файлы конфигурации с суффиксом .dist. Если явно не указан файл конфигурации (а только директория, как в случае с -c app) или вовсе не указана опция -c и файл phpunit.xml присутствует (например, для конфигурации с code coverage), будет использован он, если же его нет, будет использован phpunit.xml.dist (если существует).
Пруф: If phpunit.xml or phpunit.xml.dist (in that order) exist in the current working directory and --configuration is not used, the configuration will be automatically read from that file.

Я честно вообще не понял какой смысл копировать phpunit.xml и запихивать в gitignore. Какой смысл делать свой, эксклюзивный конфиг для тестов которые должны у всех отрабатывать одинаково?

Это очень просто. Например у нас есть CI и для него нужен специальный printer, и он должен включатся по умолчанию, что бы не делать лишних телодвижений. При этом большинство использует phpstorm для запуска тестов, и ему не столь важно какой по умолчанию стоит printer. Но есть человек который запускает тесты из консоли, и ему удобно использовать стандартный принтер для консоли, и вот что бы ему каждый раз при запуске тестов не прописывать нужный printer, он может положить рядом изменённых phpunit.xml который заменит при исполнении phpunit.xml.dist и будет использоваться, и теперь ему не нужно каждый раз дописывать опции при запуске тестов.

Окей. А теперь представим стандартную сетуацию. Изменился phpunit.xml.dist. У всех пользователей он обновится и тесты будут отрабатывать по новому, а у тех кто использует phpunit.xml, тесты будут работать по старому. А по скольку файл phpunit.xml.dist меняется редко, то это изменение может пройти очень незаметно если явно не сказать всем разработчикам. Я конечно утрирую, но такой кейс не стоит исключать.


Ну и для облегчения запуска из консоли со своими флагами, не проще ли написать bash скрипт? Да и вводить команду в консоли целиком не обязательно. Ctrl+R ни кто не отменял. Команду на code coverage я никогда не ввожу сам

Да такой случай может быть, но это не проблема, ибо если у разработчика тесты проходят, а на CI нет, то понять что проблема в phpunit.xml не так сложно, и они тут же его приведут к общему виду. И снова нет проблемы, и снова всем удобно.

Не баш, потому что это просто менее удобно.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.