[Из песочницы] Автономизация Unit-тестов в PHPUnit28.04.2020 13:03

Всем привет!

Меня зовут Антон и сейчас (не так долго, около года) я разрабатываю на PHP в одном большом и старом проекте. Для обеспечения качества проекта мы применяем автотесты на фреймворке PHPUnit. Но, к сожалению, так получилось, что большая часть наших автотестов функциональные. Недавно мы поняли, что если мы продолжим использовать автотесты прежним образом, то скоро время, потраченное на решение проблем с их не прохождением на CI станет больше, чем время, затраченное на написание полезного кода (на самом деле нет, но оно растёт и это не приятно).

Для системного решения этой проблемы мы выбрали подход, который предполагает написание множества unit-тестов и минимального количества фунциональных тестов. Так же мы решили, что в рамках изменений существующего кода необходимого по правилу бойскаута актуализировать существующие тесты. Некоторое время — все это время мы пилили новые фичи — у нас все было прекрасно. Но недавно мне прилетела задача исправить багу в старом коде. Я начал писать unit-тесты, и понял, что проснулось древнее зло легаси. Стало понятно, что это путь в никуда:

• я писал пару тест-кейсов несколько часов;
• понял, что за это время написал очень, очень много повторяющегося кода;
• фактически не сделал полезной работы;
• в случае изменения DI придется потратить очень много времени на бесполезную адаптацию кода теста.

Эта статья о том, как я решил проблему отказа от написания не несущего ценности кода. Под катом — итоговый вид тест кейса, с исключением большей части механического кода

Название статьи отсылает к автоматизации в стиле канбан — с одной стороны мы выполнили автоматизацию, а с другой стороны — все ключевые решения принимаются человеком.

Как стало

diConstParam
            ->set("value")
        ;

        // behaviour
        $this
            ->dependencyRepository
            ->expects($this->once())
            ->method('findData')
            ->with(10, 10)
            ->will($this->returnValue([]))
        ;

        // SUT
        $clazz = $this->getTestedClass();

        // act
        $res = $clazz->getData();

        // asserts
    }
}

Как было

Было плохо. Была бесконечная спагетти из генерации моков для зависимостей, длиннющий вызов конструктора в тест-кейсе. В общем, было некрасиво, и где-то внизу статьи заметно обрезанный пример такого теста приведен.

Немного боли в наших условиях

К сожалению, наш проект использует PHPUnit 3.x. Да, я знаю что он перестал поддерживаться еще до 2014(!) года, но, к сожалению, мы не можем от него отказаться в локальном масштабе времени.

Решенные проблемы

Проблемы, которые пришлось решать — это следствие большого количества старого кода, который написан в стиле, который не очень удобно покрывать автотестами. Основная проблема кода, которая решалась — это огромное (действительно, очень большое, иногда больше 20) число зависимостей в классах-сервисах, которые, на самом деле, являются первыми кандидатами на покрытие unit-тестами в связи с достаточно большим количеством ветвлений, граничных случаев и циклов.

Анализ показал, что, непосредственно «к ручной генерации» кода приводит:

1. Необходимость мокировать все зависимости серсивов в методе setUp.
2. Необходимость освобождать память моков методе tearDown. Возможно, это не обязательно, но по нашей конвенции мы это делаем
3. Необходимость создавать объект для тестирования в каждом тест-кейсе.

Как проходил поиск решения

Рассмотрим повторяющиеся фрагменты кода.

Генерация моков

Повторяющийся фрагмент кода:

$this->service = $this
    ->getMockBuilder(Service::class)
    ->disableOriginalConstructor()
    ->getMock()
;

У PHP есть хороший кандидат на то, чтобы спрятать монотонную эту монотонную работу — магическая функция:

__get

Но нам еще надо передать тип, который мы мокируем. И тут нашлось подходящее средство — phpDoc:

@property Type $service

В нашем случае, особенно с учетом возможностей современных IDE удобней всего оказалось задать его в следующем формате:

@property \FQCN\Service|\PHPUnit_Framework_MockObject_MockObject $service

Внутри функции __get абстрактного класса Intellegence_PHPUnit_Framework_TestCase происходит метапрограммирование, которое парсит phpDoc и формирует на его основе моки, доступные в виде $this→propertyName в тестовом классе. Внимание, весь приведенный в статье код является немного псевдокодом, полная версия — в репозитории:

abstract class Intelligent_PHPUnit_Framework_TestCase extends PHPUnit_Framework_TestCase {
   public function __get(string $name)
    {
        // propertyBag содержит уже готовые моки сервисов, которые хранятся по ключу имени переменной в phpDoc property
        $property = $this->getPropertyBag()->get($name);
        if ($property === false) {
            throw new Exception("Invalid property name: ${name}");
        }

        return $property;
    }

    private function getPropertyBag(): PropertyBag
    {
            if ($this->propertyBag === null) {
               // Парсинг проходит в отдельном классе
               $this->propertyBag = (new DocCommentParser())
                   ->parse(
                        // Рефлексия по извлечению phpDoc происходит по FQCN класса. Мы получаем FQCN родительского класса, в котором и описываются требуемые сервисы
                        get_class($this),
                        // Создание мока происходит через callback, поскольку функция getMockBuilder - часть базового класса для unit-тестов
                        function (string $className): PHPUnit_Framework_MockObject_MockObject {
                            return $this->createDefaultObjectMock($className);
                        }
                    );
            }

            return $this->propertyBag;
    }
}

Как можно заметить, непосредственно парсинг phpDoc вынесен в отдельный класс. Давайте посмотрим на него:

class DocCommentParser
{
    /**
     * @param string $className
     * @param callable $mockCreator
     * @throws Exception
     * @return PropertyBag
     */
    public function parse(
        string $className,
        callable $mockCreator
    ): PropertyBag {
        /** @var string[] $res */
        $r = new ReflectionClass($className);
        // Непосредственное извлечение phpDoc
        $docComment = $r->getDocComment();

        if ($docComment === false) {
            return new PropertyBag([]);
        }

        return $this->parseDocString($docComment, $mockCreator);
    }

    private function parseDocString(
        string $docComment,
        callable $mockCreator
    ): PropertyBag {
        /** @var string[] $map */
        $map = [];
        /** @var string[] $constructorParams */
        $constructorParams = [];

        // Находим все строки-кандидаты на шаблон: property Type1|Type2 $propertyName
        // Осталась именованная группа mock, потому что DI может содержать не только сервисы, но и константы
        preg_match_all('/@property\s*(?(\S*)\|(\S+)\s*\$(\S+))/', $docComment, $matches, PREG_SET_ORDER);
        foreach ($matches as $match) {
            if (array_key_exists('mock', $match) && !empty($match['mock'])) {
                // Если из указанных типов не является моком - это не наш кандидат
                // Это дополнительный предохранитель
                if ($this->isMockObject($match[2])) {
                    $map[$match[4]] = $mockCreator($match[3]);
  
                    continue;
                }

                if ($this->isMockObject($match[3])) {
                    $map[$match[4]] = $mockCreator($match[2]);

                    continue;
                }
            }
        }

        return new PropertyBag($map);
    }
}

Чего же мы достигли на данный момент? Из того, что мне не нравится — необходимость использовать FQCN в phpDoc property для клиентских зависимостей. Как это побороть — не знаю, буду благодарен за любые предложения.

class ServiceTest extends PHPUnit_Framework_TestCase
{
    /** @var DependencyRepository|PHPUnit_Framework_MockObject_MockBuilder */
    private $repository;
    protected function setUp()
    {
        parent::setUp();
        $this
            ->repository = $this->getMockBuilder(DependencyRepository::class)
            ->disableOriginalConstructor()
            ->getMock()
        ;    
    }

    protected function tearDown()
    {
        $this->repository = null;
        parent::tearDown();
    }

    public function test_test()
    {
         // $this->repository = ...
    }
}

/** @property PHPUnit_Framework_MockObject_MockObject|\Company\AnotherBundle\Repository\DependencyRepository $repository */
class ServiceTest extends Intelligent_PHPUnit_Framework_TestCase
{
    public function test_test()
    {
         // $this->repository = ...
    }
}

Писать одну строчку кода вместо 3–4–5 (зависит от вашей конвенции) — интересно. Если обратить внимание, что даже в хорошем классе, например, 7 зависимостей — здорово. С учетом того, что у меня было по 20 зависимостей — просто праздник какой-то.

Создание экземпляра тестового класса

На данный момент заметно ускорилось создание теста. Ура! Но когда я стал писать тест-кейсы, то понял, что боль все еще со мной.

Пример повторяющегося кода:

public function test_case()
{
    // SUT
    // Так может быть, поскольку, в принципе через DI можно пробросить динамические объекты.
    // Например, значение вызова функции другого объекта DI.
    $this->clazz = $this->createTestClass(
        $dependency1,
        $dependency2,
        $dependency3 //, ...
    );
}

Фактически, нам нужно вызвать одну и туже функцию с одним и тем же набором параметров во всех тест кейсах. На этот случай у php есть магическая функция __call, а в phpDoc подходящая аннотация method.

Постойте, постойте, но ведь конструктору нужен еще и набор параметров в определенном порядке?! Точно, и фактически мы их задали аннотациями property! Это очень радостный момент, когда в твоем коде возникает такая синергия. Будем считать, что порядок задания property — это порядок следования аргументов конструктора. На мой взгляд — терпимое допущение, на практике оно не сильно мешает.

Итак, мы будем использовать следующие конструкции:

/**
 * @method FQCN\TestedService getTestedClass()
 */
class ServiceTest
{
    public function test_case()
    {
         // SUT
         $clazz = $this->getTestedClass();
    }
}

Давайте посмотрим на реализацию магической функции __call:

abstract class Intelligent_PHPUnit_Framework_TestCase extends PHPUnit_Framework_TestCase
{
    private const GET_TESTED_CLASS_METHOD_NAME = 'getTestedClass';

    /**
     * @param string $method
     * @param array $params
     * @throws Exception
     * @return object
     */
    public function __call(string $method, array $params)
    {
        if ($method !== self::GET_TESTED_CLASS_METHOD_NAME) {
            throw new Exception("Invalid method name: ${method}");
        }

        if (!array_key_exists(self::GET_TESTED_CLASS_METHOD_NAME, $this->getMethodsMap())) {
            throw new Exception('Method ' . self::GET_TESTED_CLASS_METHOD_NAME . ' not annotated');
        }

        // Обратите внимание, что PropertyBag расширился и теперь запоминает порядок следования аннотаций property - порядок следования аргументов конструктора
        $params = $this->getPropertyBag()->getConstructorParams();
        $paramValues = [];
        foreach ($params as $param) {
            $property = $this->__get($param);
            $paramValues[] = $property;
        }

        $reflection = new ReflectionClass($this->getMethodsMap()[self::GET_TESTED_CLASS_METHOD_NAME]);
        // Через рефлексию получаем экземпляр тестового класса с нужными аргументами
        return $reflection->newInstanceArgs($paramValues);
    }
}

Как изменился парсер? Теперь формирует помимо моков еще и порядок следования заданных property:

class DocCommentParser
{
    /**
     * @param string $className
     * @param callable $mockCreator
     * @throws Exception
     * @return PropertyBag
     */
    public function parse(
        string $className,
        callable $mockCreator
    ): PropertyBag {
        /** @var string[] $res */
        $r = new ReflectionClass($className);
        $docComment = $r->getDocComment();

        if ($docComment === false) {
            // Передаем пустой порядок следования аргументов
            return new PropertyBag([], []);
        }

        return $this->parseDocString($docComment, $mockCreator);
    }

    private function parseDocString(
        string $docComment,
        callable $mockCreator
    ): PropertyBag {
        /** @var string[] $map */
        $map = [];
        /** @var string[] $constructorParams */
        $constructorParams = [];

        preg_match_all('/@property\s*(?(\S*)\|(\S+)\s*\$(\S+))/', $docComment, $matches, PREG_SET_ORDER);
        foreach ($matches as $match) {
            if (array_key_exists('mock', $match) && !empty($match['mock'])) {
                if ($this->isMockObject($match[2])) {
                    $map[$match[4]] = $mockCreator($match[3]);
                    // Запоминаем порядок следования аргументов
                    $constructorParams[] = $match[4];

                    continue;
                }

                if ($this->isMockObject($match[3])) {
                    $map[$match[4]] = $mockCreator($match[2]);
                    // Запоминаем порядок следования аргументов
                    $constructorParams[] = $match[4];

                    continue;
                }
            }
        }

        return new PropertyBag($map, $constructorParams);
    }
}

Прямо сейчас мы избавились от необходимости писать однотипные вызовы по генерации моков и однотипные вызовы по формированию тестового класса. Суммарно, это достаточно заметное число строк кода. Даже если считать, что в класс через DI пробрасываются только статически-мокируемые параметры, то есть, в тесте можно написать приватный метод без параметров, который вернет тестируемый класс — это все равно некоторое улучшение, которое позволяет отказаться от написания бесполезного кода

class ServiceTest extends PHPUnit_Framework_TestCase
{
    /** @var DependencyRepository|PHPUnit_Framework_MockObject_MockBuilder */
    private $repository;
    protected function setUp()
    {
        parent::setUp();
        $this
            ->repository = $this->getMockBuilder(DependencyRepository::class)
            ->disableOriginalConstructor()
            ->getMock()
        ;    
    }

    protected function tearDown()
    {
        $this->repository = null;
        parent::tearDown();
    }

    public function test_test()
    {
        $this->clazz = $this->createTestClass(repository);
    }

    private function createTestClass() {
        return new TestedService($repository)
    }
}

Статические значения

В библиотеке из репозитория также есть возможность пробрасывать статические значения через ConstDependencyInjectionParameter. Но это в достаточной мере механическая адаптация уже рассмотренного подхода, поэтому она останется за рамками этой статьи.

Ссылка на исходный код

© Habrahabr.ru