Перед первой доработкой старого PHP-проекта зафиксируйте поведение затрагиваемого сценария: с какими данными он запускается, что возвращает и что меняет. Для руководителя проекта результат этой подготовки — небольшой набор воспроизводимых проверок, по которым можно принять правку. Переписывать весь сайт ради первых тестов не требуется.
Начните с трёх безопасных действий:
- Опишите одну ближайшую правку и соседние действия, которые должны остаться прежними.
- Вместе с разработчиком выберите изолированную копию проекта и вымышленные данные для проверки.
- Согласуйте ожидаемые результаты: что сохраняем, что намеренно меняем, какие ошибки уже известны.
Как выбрать сценарии для первых тестов
Начинайте с места будущего изменения. Если меняется обработка заявки, полезнее проверить её сохранение, права доступа и передачу данных, чем покрывать тестами несвязанные служебные функции.
Для каждого соседнего сценария задайте четыре вопроса: проходит ли он через изменяемый код; насколько болезненен сбой; затрагивает ли он внешнюю систему; можно ли воспроизвести его на тестовых данных. В первую очередь берите связанные с правкой сценарии с дорогими последствиями: потерей записи, неправильным расчётом или доступом к чужим данным.
Запишите для каждого: условие → действие → наблюдаемый результат → способ проверки. Например: «пользователь без права просмотра открывает тестовую заявку → получает отказ → содержимое заявки не раскрывается». Сам по себе ответ сервера без ошибки ещё не подтверждает соблюдение прав.
Отдельно перечислите непроверяемые пока участки. Если нет безопасного способа проверить отправку во внешнюю систему, это ограничение приёмки, а не успешно пройденный тест. Общий порядок знакомства с чужим кодом разобран в статье о доработке legacy-проекта.
Что фиксировать, если документации нет
Тест наблюдаемого поведения, или characterization test, записывает, как существующий код ведёт себя при заданных условиях. Он помогает обнаружить непреднамеренное изменение после правки. Но наблюдаемое поведение не всегда правильно.
Разделите результаты на три группы:
- Сохранить: подтверждённое правило, на которое опираются пользователи или интеграция.
- Изменить: ошибка или новое требование с согласованным ожидаемым результатом.
- Уточнить: поведение обнаружено, но никто пока не подтвердил, каким оно должно быть.
Не превращайте третью группу в обязательный эталон молча. Например, если пустое поле неожиданно стирает ранее сохранённое значение, сначала выясните, используют ли этот способ для очистки. Иначе тест может закрепить дефект или новая правка нарушит нужное правило.
Для сохраняемого поведения проверка должна проходить до изменения и после него. Для исправляемой ошибки полезен отдельный тест правильного результата: он воспроизводимо не проходит на старом коде и проходит после исправления. В отчёте эти две группы должны различаться.
Учебный пример: новое поле в старой заявке
Предположим, в заявку добавляют необязательное поле «Подразделение». Это учебная ситуация, не описание выполненного клиентского проекта. Владелец согласовал: старые отправители могут не передавать новое поле, а остальные правила заявки сохраняются.
До правки разработчик фиксирует такой набор проверок:
| Сценарий | Что наблюдать |
|---|---|
| Корректная заявка прежнего формата | Создаётся запись с прежними значениями остальных полей |
| Не заполнен обязательный реквизит | Возникает предусмотренная ошибка; недопустимая запись не сохраняется |
| Заявку открывает роль без доступа | Данные не выдаются |
| Передача во внешнюю систему завершается ошибкой | Состояние заявки и обработка отказа соответствуют согласованному правилу |
Последняя строка нужна, только если обмен существует и затрагивается доработкой. Её ожидаемый результат берут из согласованного поведения проекта: нельзя по умолчанию предполагать повторную отправку или удаление записи.
После этого добавляют проверки нового требования: поле отсутствует; поле передано пустым; передано допустимое значение. Для каждого варианта заранее определяют, что хранится и что получает внешняя система. Если пустая строка и отсутствие поля должны означать одно и то же, это решение фиксируют явно.
Для заявки с новым значением проверяют всю нужную цепочку: значение принято, сохранено, затем правильно прочитано. Видимое поле на экране не доказывает сохранение в базе. Если меняется обмен, отдельно проверяют состав передаваемых данных; успех тестовой заглушки не доказывает совместимость с настоящим сервисом.
Где запускать проверки и что изолировать
Тестовые данные — заранее подготовленное исходное состояние, которое можно восстановить перед следующим прогоном. Используйте вымышленные записи и отдельную базу. Копировать рабочую базу с персональными данными ради удобства тестов не следует.
До запуска разработчик проверяет подключения приложения, фоновых заданий и очередей: они должны вести в тестовые ресурсы. Почту направляют в тестовый приёмник, платежи и обмены — в разрешённый тестовый режим либо заменяют управляемыми заглушками. Защиту и проверку прав сохраняют.
Копия файлов ещё не означает изоляцию. Если приложение использует рабочие подключения, токены или очередь, тест может изменить реальные данные или отправить настоящее уведомление.
Заглушка позволяет задать ответ внешней зависимости: например, успешное подтверждение или отказ. Это удобно для проверки реакции приложения. Отдельная интеграционная проверка нужна там, где важно взаимодействие с реальной тестовой базой или официальной песочницей сервиса.
В старом PHP-коде запуск файла может сразу открывать соединение, отправлять письмо или менять глобальное состояние. Сначала найдите эти действия. Если безопасно подключить файл нельзя, начните с проверки через доступную границу — например, тестовый HTTP-запрос — и отдельно оцените выделение нужной логики. Массовая перестройка кода до фиксации поведения увеличит объём непроверенных изменений.
Как выбрать инструмент и принять набор тестов
PHPUnit подходит для проверок PHP-кода, но его выпуск должен быть совместим с интерпретатором и зависимостями проекта. Разработчик сверяет требования выбранной версии, ограничения Composer и документацию именно этой ветки. Установка последнего PHPUnit не должна незаметно превращаться в обновление PHP и библиотек рабочего сайта.
Если окружение устарело, отделите подготовку первых проверок от плана обновления. Совместимость старого инструмента с проектом сама по себе не означает, что его поддержка продолжается.
Принимайте набор по наблюдаемым признакам:
- Описаны версия кода, тестовое окружение, исходные данные и способ запуска.
- Повторный прогон с восстановленными данными даёт тот же результат.
- Проверяется содержательный результат: значение, сохранённая запись, отказ в доступе или нужный побочный эффект.
- Нестабильные значения, например время, управляются явно; важные поля не исключены из сравнения ради зелёного отчёта.
- Число запущенных проверок соответствует плану; пропущенные проверки и ошибки самого запуска разобраны.
- Новое требование проверяется отдельно, а прежние согласованные сценарии продолжают работать.
Чтобы убедиться, что проверка действительно работает, разработчик может временно задать заведомо неверное ожидание в изолированной копии. Оно должно вызвать понятное падение теста; затем ожидание возвращают. Такая проверка механизма не заменяет доказательства, что тест ловит нужный дефект.
Процент покрытия кода не заменяет эту приёмку: выполненная строка ещё не означает проверенное правило. После подготовки тестов остаётся согласовать выпуск и откат — это отдельный процесс внедрения доработки.
Когда достаточно своей команды
Если разработчик может изолировать проект, воспроизвести сценарий и объяснить ожидаемый результат, начать с такого набора можно своими силами. Руководителю полезно проверить понятность условий и результата; читать внутреннее устройство каждого теста для этого не нужно.
Если проверки запускаются только на рабочем сервере, зависимости не удаётся отделить или смысл старого поведения неизвестен, сначала нужна диагностика границ задачи. Набор тестов не гарантирует отсутствие всех ошибок и не заменяет проверку безопасности, производительности или восстановления данных.
OpenStart занимается доработкой действующих сайтов и разбором старого кода. Для оценки такой задачи полезно подготовить описание ближайшего изменения, текущего поведения и способа приёмки. На странице доработки сайта описан порядок работы: сначала уточняются исходные данные и объём задачи, затем согласуется оценка.