Можно ли быстро актуализировать старые PHPUnit-тесты под новые версии пакета?

Краткий ответ: да, но есть нюансы.

На Хабре незаслуженно мало статей про инструмент Rector, и даже в них совсем вскользь упоминается, что у инструмента есть отдельный функционал для актуализации PHPUnit-тестов, написанных под разные версии пакета. Причем если раньше, этот функционал был в виде отдельного пакета rector-phpunit, то на сегодня (для версии 2.6.3) этот функционал уже входит в состав основного пакета.

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

Как шло обновление:
- установили пакет rector/rector
- обновили пакет phpunit
- сделали файл конфига rector.php в котором прописали наборы правил
- запустили сначала в режиме vendor/bin/rector process --dry-run. Увидели, что аннотации @dataProvider не мигрировали в атрибуты #[DataProvider], а сами методы, на которые указывают dataProvider не стали статическими (требования PHPUint 10+).
Добавили необходимые правила в конфиг rector.php и в при первом приближении всё сработало как нужно:

<?php

declare(strict_types=1);

use Rector\Config\RectorConfig;

return RectorConfig::configure()
    // Путь к директории с тестами
    ->withPaths([
        __DIR__ . '/tests',
    ])
    // Включаем синтаксис PHP 8.4
    ->withPhpSets(php84: true)
    // Правила берем для версии phpunit из composer.json
    ->withComposerBased(
        phpunit: true
    )
    // Общие наборы правил для улучшения качества тестов
    ->withPreparedSets(
        phpunitCodeQuality: true
    )
    // Явно запускаем встроенное правило миграции аннотаций PHPUnit в атрибуты
    ->withAttributesSets(
        phpunit: true
    );

Но и после этих инструкций не все методы dataProvider стали статическими. Основные причины были в следующем:
- использование $this в методах dataProvider
- коллизии из-за последовательности выполнения правил рефакторинга в Rector

Что помогло исправить ситуацию:
1. повторный запуск vendor/bin/rector process позволил правилам повторно пройтись по уже исправленным файлам и доделать изменения
2. использование ссылки на текущий объект в методах dataProvider плохая практика, от неё отказались

Лучше не сохраняйте в сессии PHP объекты с защищенными или приватными свойствами, если сама сессия хранится в БД.

Оговорюсь, что не поддерживаю сохранение объектов в сессиях PHP, а пример взят из Legacy-проекта, в котором компонент рекомендованных продаж клиенту реализован в виде класса. Видимо предыдущие разработчики посчитали удобным не париться с сохранением рекомендаций в виде отдельной структуры, а сохраняли класс прямо в сессию клиента. Сами сессии хранятся в БД MySQL (тоже тема для отдельной дискуссии).

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

Немного теории. Оказалось, что PHP сохраняет свойства объектов в сессии с определенными особенностями:

• публичные свойства `public $item` сохраняются как item

• защищенные свойства `protected $item` сохраняются как \0*\0item

• приватные свойства `private $item` сохраняются как \0ClassName\0item

причем \0 это нулевой байт. Главной проблемой стало то, что MySQL воспринимал этот нулевой байт как конец строки и сохранял в таблицу обрезанную строку. Сессия становилась невалидной.

Самое простое решение в данном случае изменить тип поля на BLOB, в этом случае текст корректно сохранится побайтово. По поводу вопроса, стоит ли сохранять объекты в сессию пользователя, каждый думаю решит для себя сам.

Функция date меняет поведение в PHP 8.x

При переносе Legacy-проекта с PHP 7.4 на 8.4 столкнулся с недокументированной проблемой изменения поведения функции date при передаче в качестве параметра timestamp значения NULL Один и тот же код даст разный результат:

echo date("Y-m-d H:i:s", null);

// PHP 7.4 и ниже 1970-01-01 00:00:00

// PHP 8.0 и выше 2026-01-14 08:11:56

В примере NULL передается в явном виде, но в рабочем коде он вполне может прилетать из БД или других переменных, поэтому потенциальная ошибка может остаться незамеченной. Вообще, по принципам ООП, явное всегда лучше неявного, да и сам я сторонник использования \DateTime. В этом случае, результат кода:

$date = new \DateTime();
$date->setTimestamp(null);
echo $date->format("Y-m-d H:i:s");

был бы одинаковый, а с версии 8.1 вы бы начали получать предупреждение

Deprecated: DateTime::setTimestamp(): Passing null to parameter #1 ($timestamp) 
of type int is deprecated
1970-01-01 00:00:00

Я бы рекомендовал перед миграцией версий PHP в Legacy-проектах либо учитывать эту особенность поведения функции date и убедиться, что NULL не приходит в параметр timestamp, либо сразу сделать рефакторинг на \DateTime, чтобы в принципе избежать таких проблем.