Шаг 1: Знакомство с новым синтаксисом и его влияние на тестовое покрытие.
Одно из главных нововведений — **явная типизация для свойств класса в анонимных классах**. Раньше объявить тип свойства внутри анонимного класса было нельзя. Теперь можно. Для тестировщика это означает, что при анализе кода, использующего анонимные классы (часто в тестах или фабриках), нужно проверять соответствие присваиваемых значений заявленным типам. Упадет ли тест, если разработчик ошибется? Да, если включен strict режим. Рекомендация: обновить статические анализаторы (Psalm, PHPStan) до версий, поддерживающих PHP 8.4, и запустить их на кодовой базе.
Другая синтаксическая «вкусность» — возможность использовать **сокращенный синтаксис для переопределения методов в анонимных классах**. Раньше нужно было писать полный метод. Теперь можно использовать стрелочный синтаксис для простых переопределений. Это может увеличить читаемость тестовых дублеров (mock-объектов), создаваемых на лету. Тестировщикам, пишущим интеграционные тесты, стоит знать этот синтаксис.
Шаг 2: Анализ Breaking Changes — главный фокус для обеспечения стабильности.
Это самый критичный этап. PHP 8.4, как минорная версия, не должен ломать многое, но изменения есть.
* **Изменения в функциях даты и времени**: Функции `date()` и `gmdate()` теперь выбрасывают `DateError` вместо предупреждения, если передана неверная временная метка. Для тестировщика это означает, что E2E-тесты или тесты API, которые косвенно зависят от этих функций и передают некорректные даты, теперь будут получать исключение, а не молчаливо работать с ошибкой. Нужно проверить сценарии с ошибочными данными даты.
* **Поведение `htmlspecialchars()` и `htmlentities()`**: По умолчанию теперь используется кодировка `UTF-8`, а не значение из `php.ini`. Это может повлиять на вывод веб-приложений, работающих с другими кодировками. Необходимо провести smoke-тестирование всех страниц, особенно тех, где используется контент на национальных языках (кириллица, иероглифы).
* **Устаревание (Deprecation) ряда функций**: Например, `convert_cyr_string()`, `hebrevc()`. Тестировщик должен настроить окружение так, чтобы предупреждения об устаревании (E_DEPRECATED) были видны в логах тестов или CI/CD пайплайна. Это поможет разработчикам заранее мигрировать с устаревшего кода.
Шаг 3: Изучение новых классов и функций для улучшения тестов.
PHP 8.4 приносит новую **библиотеку для работы с URI** — класс `Uri`. Это самостоятельная, независимая от HTTP-контекста реализация PSR-7. Для тестировщика, пишущего тесты для API-клиентов или роутинга, это отличная возможность заменить кастомные или неуклюжие конструкции по работе с URL на стандартизированный класс. Можно использовать его в тестах для удобного построения ожидаемых URL.
Шаг 4: План действий по тестированию приложения на PHP 8.4.
- **Подготовка окружения**: Установите PHP 8.4 (альфа/бета-версию) параллельно с текущей стабильной. Настройте отдельную конфигурацию в вашем CI/CD (например, job в GitHub Actions).
- **Статический анализ**: Запустите обновленные статические анализаторы и linter (PHP_CodeSniffer) на всей кодовой базе. Сфокусируйтесь на ошибках, связанных с новыми типами и устаревшими функциями.
- **Запуск юнит-тестов**: Это самый быстрый индикатор проблем. Убедитесь, что все юнит-тесты проходят. Особое внимание — тестам, которые работают с датами, строками и анонимными классами.
- **Интеграционное и функциональное тестирование**: Проверьте ключевые бизнес-сценарии. Из-за изменений в функциях даты или кодировках могут «всплыть» проблемы, не пойманные юнитами.
- **Тестирование производительности (опционально, но желательно)**: PHP 8.4 обещает дальнейшие улучшения JIT-компилятора. Запустите benchmarks-тесты для критичных к производительности участков кода, чтобы зафиксировать возможный прирост (или регрессию).
- **Составление отчета**: Задокументируйте все найденные проблемы, разделив их на критические (breaking changes), предупреждения (deprecations) и рекомендации (использование нового синтаксиса).
Комментарии (8)