Тестирование на PHP

Набор тестов покупает одну вещь — возможность менять код и узнавать о поломке за секунды, а не от пользователя. Но покупает ровно настолько, насколько тесты действительно поймали бы дефект. Здесь и проходит водораздел темы: инструменты покрытия отвечают на вопрос «какие строки исполнились», а не «какая ошибка была бы замечена», и набор, где нет ни одного assert, честно отчитается о стопроцентном покрытии. Всё остальное в теме — способы приблизить второй вопрос к первому.

Ловушки называем сразу, потому что почти каждая из них выглядит как успех. Мок кодирует ваше предположение о чужой зависимости — и остаётся зелёным, когда предположение перестало быть верным. RefreshDatabase откатывает транзакцию, поэтому собственный commit в тестируемом коде из-под отката уходит, а второе соединение — очередь, браузерный драйвер — незакоммиченных строк просто не видит. In-memory SQLite — не быстрый MySQL, а другой движок с другим диалектом: зелёный прогон на нём ничего не говорит про запросы, которые пойдут в продакшен. Упавший снапшот чинится «регенерацией» — и регрессия оказывается молча одобрена. Разбор по слоям — ниже.

Карта темы

• Что такое тест — структура Arrange–Act–Assert, правило одного действия и почему проверять надо поведение, а не реализацию.
• PHPUnit — жизненный цикл и data provider — свежий экземпляр тест-класса на каждый метод, setUp/tearDown вместо конструктора и провайдер данных, который называет упавший вход.
• Pest — синтаксис поверх PHPUnit — DSL из замыканий, исполняемый тем же движком, и почему миграция «всем разом» не нужна.
• Мокирование зависимостей — стаб, мок и спай, шов для подмены, внедрённые часы и цена пере-мокирования.
• Unit- и feature-тесты в Laravel — что поднимает фреймворк, а что нет, фейки на границе диспатча и цена снапшотов.
• Тестовая база данных — как RefreshDatabase откатывает транзакцию, где откат молча не срабатывает и почему SQLite — другой движок.
• Мутационное тестирование — чем Infection отличается от покрытия и что означает выживший мутант.
• Статический анализ — что PHPStan находит, не исполняя код, и почему он не заменяется ни strict_types, ни тестами.
• Стандарты кода — PSR-1, PSR-12 и PSR-4, phpcs/phpcbf и три уровня контроля.

Частые ошибки и ловушки

Значение для собеседований

Тестирование спрашивают не вопросом «пишете ли вы тесты», а вопросом «что ваш набор доказывает и чего он не ловит». Кандидат, который умеет назвать границы собственного набора — «покрытие показывает исполнение, поэтому я гоняю Infection на изменённых файлах», «мок провайдера ничего не доказывает про провайдера, поэтому контракт проверяется на его стороне» — сразу отделяется от того, кто отвечает процентом покрытия.

Что обычно проверяют:

• Три фазы AAA и почему действие должно быть ровно одно.
• Жизненный цикл PHPUnit — свежий экземпляр на тест, setUp против конструктора.
• Что делает data provider и как он отчитывается о падении конкретного входа.
• Чем Pest является по отношению к PHPUnit и что именно в нём меняется.
• Разницу стаба, мока и спая и цену проверок взаимодействия.
• Как сделать код с time() детерминированным и почему не через глобаль.
• Границу unit- и feature-теста в Laravel и что доказывает каждый.
• Что RefreshDatabase делает на самом деле и где он молча ломается.
• Почему SQLite в тестах при MySQL в проде — не оптимизация, а потеря доказательства.
• Что меряет мутационное тестирование сверх покрытия.
• Какие дефекты статический анализатор находит без запуска кода.

Типичный неверный ответ: «у нас покрытие 90%, значит регрессии мы ловим». Отсюда обычно и начинается разговор: покрытие фиксирует, что строка исполнилась, а не что её поломку кто-то заметил бы — набор, где закомментированы все assert, покажет ровно те же 90%. Второй классический провал — «RefreshDatabase очищает базу перед каждым тестом»: он оборачивает тест в транзакцию и откатывает её, и именно поэтому он быстрый, и именно поэтому он бессилен против кода, который коммитит сам.