PHPUnit ломается не там, где падает тест, а там, где тест слишком много обещает

PHPUnit ломается не там, где падает тест, а там, где тест слишком много обещает

Если тесты стали медленнее и шумнее, сначала проверь не код, а саму форму проверки. Частые проблемы:
— один тест зависит от порядка запуска;
— фикстуры создаются через общие статические объекты;
— в ассертах проверяют не поведение, а внутренности класса;
— мокают всё подряд, включая то, что проще поднять настоящим объектом.

Хороший PHPUnit-тест отвечает на один вопрос: «если я меняю поведение, сломаю ли я контракт?». Для этого держи тест коротким, изолированным и с одним смыслом. Если в одном методе есть и подготовка, и сложный акт, и пять проверок — это уже мини-сценарий, а не unit-тест.

Ещё одна типовая ловушка: тестируют то, что и так гарантирует фреймворк или библиотека. Такой код только раздувает suite и добавляет ложную уверенность. Лучше прикрыть свои адаптеры, бизнес-ветки и места, где есть преобразование данных, условия, исключения, границы.

Сильный набор на PHPUnit — это не максимум моков, а минимум сюрпризов. Если тест сложно прочитать за 10 секунд, его почти наверняка сложно и поддерживать.