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

Стандарты кода — это семейство PSR: PSR-1 и PSR-12, проверяемые инструментами вроде PHP_CodeSniffer. Основные раннеры тестов — PHPUnit и Pest. Чтобы изолировать код от внешних зависимостей, их мокают: createMock() из PHPUnit, библиотека Mockery или тест-дубли, внедряемые через конструктор (DI). Вы проверяете дубль вместо обращения к реальной сети или базе.

Unit-тест проверяет один класс в изоляции, подменяя его зависимости дублями, и по умолчанию не поднимает фреймворк. Feature-тест поднимает приложение, поэтому может дёрнуть маршрут через $this->get('/orders'), ходить в базу и проверять HTTP-ответ. Feature-тесты доказывают связность, unit-тесты точнее указывают на дефект.

Arrange создаёт тестируемый объект и его входные данные. Act вызывает ровно одно поведение — обычно один метод. Assert сравнивает наблюдаемый результат с ожиданием. Разделение фаз и единственное действие оставляют тесту одну причину падения, поэтому красный тест точно указывает, какой вызов сломался.

Pest — это DSL поверх PHPUnit, а не отдельный движок: вы пишете замыкания it('...', fn() => ...) вместо методов у TestCase, а исполняет их по-прежнему PHPUnit. Проверки, моки и конфигурация PHPUnit продолжают работать, а классические классы TestCase живут в том же наборе. Меняется стиль написания, а не раннер.

Он разбирает исходники и рассуждает о типах и достижимости, ничего не выполняя: вызовы несуществующих методов, неверные типы аргументов и возврата, всегда ложные условия, недостижимый код, отсутствующие проверки на null. Он читает и generics из докблоков, которые движок игнорирует. Строгость задаётся уровнем, поднимаемым постепенно.

Data provider — это метод, возвращающий наборы аргументов. PHPUnit прогоняет тест по разу на каждый набор, передавая его в параметры тест-метода, и показывает каждый набор отдельным тестом со своим именем — поэтому падение называет точный вход. А foreach внутри одного теста встал бы на первом плохом случае, скрыв остальные.

Стаб возвращает заготовленные данные и ничего не проверяет — он лишь даёт коду отработать. Мок заранее задаёт ожидания по вызовам, например expects($this->once()), и роняет тест, когда они не выполнены. Шпион записывает вызовы для проверки после действия. Проверка взаимодействий привязывает тест к тому, как код зовёт зависимости.

SQLite — это другой движок, а не быстрый MySQL: другой диалект, более вольная типизация, другое поведение ограничений и дат. Зелёный прогон на SQLite ничего не доказывает о запросах, которые пойдут в проде, — именно это у вас и сломалось. Тестируйте на том же движке, что и в проде, держа скорость откатом транзакции в CI.

PHPUnit создаёт новый экземпляр тест-класса на каждый тест-метод, вызывает setUp() перед ним и tearDown() после. Конструктор работает вне этого жизненного цикла: у него фиксированная сигнатура, нет парного teardown, а сбой в нём не сообщается как обычный провал теста. setUp() — штатная точка расширения.

Внедрите часы вместо вызова глобальной функции. Объявите интерфейс Clock с методом now(): int, примите его в конструкторе и зовите $this->clock->now(). В проде подставляется SystemClock, возвращающий time(); в тест передаётся замороженный clock с фиксированной меткой. Глобальное состояние не трогается, поэтому тесты остаются изолированными и могут идти параллельно.

Он оборачивает каждый тест в транзакцию базы и откатывает её в конце, поэтому схема мигрируется один раз, а каждый тест стартует из одного состояния без очистки таблиц. Отсюда и скорость. Ломается он, когда тестируемый код сам делает commit или когда второе соединение — воркер, браузер — не видит незакоммиченных строк.

Они закрывают разные окна. Объявление типа срабатывает лишь на строке, до которой запрос реально дошёл; тест доказывает только те пути, которые он проходит. Статический анализатор проверяет все пути в исходниках ещё до запуска и понимает generics из докблоков, невыразимые для движка. CI гоняет все три сразу.

Покрытие строк фиксирует лишь то, какие строки выполнились. Infection мутирует исходник — меняет > на >=, инвертирует условие, убирает return — заново гоняет набор и смотрит, упал ли тест. Выживший мутант — это дефект, который ваши тесты не поймали бы. Набор вовсе без проверок покажет полное покрытие.

Мок кодирует ваше предположение о провайдере, и никто не проверяет, что оно ещё верно. Добавьте контрактное тестирование со стороны потребителя: ваш набор записывает делаемые запросы и ожидаемые ответы в пакт, а провайдер проигрывает этот пакт против своей реальной реализации в своём пайплайне. Ваш набор быстр, а их сборка краснеет, когда они вас ломают.

Он отрисовывает представление, сравнивает вывод с закоммиченным файлом-снимком и падает на любом различии. Это дёшево писать, и оно ловит непреднамеренные правки разметки по всему слою представлений. Цена — он проверяет всё подряд: законная правка пробела или имени класса тоже роняет тест, а рефлекс — перегенерировать снимок, утвердив регрессию.

Разделите надвое. В точке отправки подмените очередь фейком и проверьте, что задача поставлена с верной нагрузкой — контракт контроллера на этом кончается. Затем протестируйте handle() как unit, внедрив шлюз и почтовик как дубли, чтобы ни списание, ни письмо не ушли. Повторы и хук падения покройте, заставив дубль бросить исключение.