PHPUnit ломает не тесты, а дисциплину: 7 ошибок, которые тихо съедают доверие
Чаще всего проблема не в самом фреймворке, а в том, как его используют:
• тестируют реализацию вместо поведения;
• мешают unit и integration в одном классе;
• делают фикстуры слишком жирными;
• полагаются на порядок запуска;
• оставляют общие состояния между тестами.
Есть ещё три ловушки, которые всплывают в больших проектах. Первая — тест без понятного имени: через месяц уже никто не помнит, зачем он нужен. Вторая — ассерты «на всё подряд», когда тест падает по любой мелочи. Третья — мокают то, что проще поднять как настоящую зависимость, и получают хрупкую конструкцию.
Хорошее правило простое: один тест — одна причина упасть. Если проверяете бизнес-правило, не тащите туда лишний фреймворк-код. Если нужен контракт с БД или HTTP, вынесите это в отдельный слой и не пытайтесь назвать его unit-тестом ради красивой папки.
И ещё: тесты должны объяснять код, а не маскировать его. Если после правки продукта падает полпакета, значит, у вас не защита, а коллекция случайных сценариев.
Laravel & PHP Deep — фреймворки и пакеты
@laravel_php_deep
PHPUnit ломает не тесты, а дисциплину: 7 ошибок, которые тихо съедают доверие
Этот пост опубликован в Telegram-канале Laravel & PHP Deep — фреймворки и пакеты. Подписаться можно по ссылке: @laravel_php_deep.