Главная
Мутационное тестирование

Мутационное тестирование +56

20.08.2017 20:40

borNfree 36 11200 Источник

Юнит тесты помогают нам удостовериться, что код работает так, как мы этого хотим. Одной из метрик тестов является процент покрытия строк кода (Line Code Coverage).

Но насколько корректен данный показатель? Имеет ли он практический смысл и можем ли мы ему доверять? Ведь если мы удалим все assert строки из тестов, или просто заменим их на assertSame(1, 1), то по-прежнему будем иметь 100% Code Coverage, при этом тесты ровным счетом не будут тестировать ничего.

Насколько вы уверены в своих тестах? Покрывают ли они все ветки выполнения ваших функций? Тестируют ли они вообще хоть что-нибудь?

Ответ на этот вопрос даёт мутационное тестирование.

Мутационное тестирование — это метод тестирования ПО, основанный на всевозможных изменениях исходного кода и проверке реакции на эти изменения набора автоматических тестов. Если тесты после изменения кода успешно выполняются, значит либо код не покрыт тестами, либо написанные тесты неэффективны. Критерий, определяющий эффективность набора автоматических тестов, называется Mutation Score Indicator (MSI).

Введем некоторые понятия из теории мутационного тестирования:

Для применения этой технологии у нас, очевидно, должен быть исходный код (source code), некоторый набор тестов (для простоты будем говорить о модульных — unit tests).

После этого можно начинать изменять отдельные части исходного кода и смотреть, как реагируют на это тесты.

Одно изменение исходного кода будем называть Мутацией (Mutation). Например, изменение бинарного оператора "+" на бинарный "-" является мутацией кода.

Результатом мутации является Мутант (Mutant) — то есть это новый мутированный исходный код.

Каждая мутация любого оператора в вашем коде (а их сотни) приводит к новому мутанту, для которого должны быть запущены тесты.

Кроме изменения "+" на "-", существует множество других мутационных операторов (Mutation Operator, Mutator) — отрицание условий, изменение возвращаемого значения функции, удаление строк кода и т.д.

Итак, мутационное тестирование создает множество мутантов из вашего кода, для каждого из них запускает тесты и проверяет, выполнились они успешно или нет. Если тесты упали — значит всё хорошо, они отреагировали на изменение в коде и поймали ошибку. Такой мутант считается убитым (Killed mutant). Если тесты выполнились успешно после мутирования — это говорит о том, что либо ваш код не покрыт в этом месте тестами вовсе, либо тесты, покрывающие мутированную строку, неэффективны и в недостаточной степени тестируют данный участок кода. Такой мутант называется выжившим (Survived, Escaped Mutant).

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

Рассмотрим пример. Будем использовать мутационный фреймворк (МФ) для PHP — Infection.

Пусть у нас есть какой-то фильтр, умеющий отфильтровывать коллекцию пользователей по признаку совершеннолетия, написанный в объектно-ориентированном стиле:

class UserFilterAge
{
    const AGE_THRESHOLD = 18;

    public function __invoke(array $collection)
    {
        return array_filter(
            $collection,
            function (array $item) {
                return $item['age'] >= self::AGE_THRESHOLD;
            }
        );
    }
}

И для этого фильтра есть юнит тест:

public function test_it_filters_adults()
{
    $filter = new UserFilterAge();
    $users = [
        ['age' => 20],
        ['age' => 15],
    ];

    $this->assertCount(1, $filter($users));
}

Тест очень простой — добавляем двух пользователей и ожидаем, что фильтр вернет только одного из них, возраст которого 20 лет.

Заметьте, при наличии только лишь этого теста, мы уже имеем 100% покрытие исходного кода класса UserFilterAge. Запустим мутационное тестирование и проанализируем результат:

./infection.phar --threads=4

При стопроцентном покрытии кода мы имеем только 67% MSI — это уже подозрительно.

Как считается MSI

Metrics:
    Mutation Score Indicator (MSI): 47%
    Mutation Code Coverage: 67%
    Covered Code MSI: 70%

Mutation Score Indicator (MSI)

MSI равен 47%. Это ознaчает, что 47% всех сгенерированных мутаций не выжили (убиты, таймауты, ошибки). MSI является главной метрикой мутационного тестирования. Если Code Coverage равен 65%, то мы получаем разницу в 18% и это говорит о том, что процент покрытия строк кода в данном случае является плохим критерием оценки тестов.

Формула подсчета:

TotalDefeatedMutants = KilledCount + TimedOutCount + ErrorCount;

MSI = (TotalDefeatedMutants / TotalMutantsCount) * 100;

Mutation Code Coverage

Данный показатель равен 67%. В целом, он должен быть примерно равен показателю Code Coverage.

Формула подсчета:

TotalCoveredByTestsMutants = TotalMutantsCount - NotCoveredByTestsCount;

CoveredRate = (TotalCoveredByTestsMutants / TotalMutantsCount) * 100;

Covered Code Mutation Score Indicator

MSI для кода, который покрыт тестами, равен 70%. Данный критерий показывает, насколько эффективны в реальности ваши тесты. То есть это процент всех убитых мутантов, сгенерированных для покрытого тестами кода.

Формула подсчета:

TotalCoveredByTestsMutants = TotalMutantsCount - NotCoveredByTestsCount;
TotalDefeatedMutants = KilledCount + TimedOutCount + ErrorCount;

CoveredCodeMSI = (TotalDefeatedMutants / TotalCoveredByTestsMutants) * 100;

Если проанализировать метрики, получается, что MSI на 18 единиц меньше, чем показатель Code Coverage. Это говорит о том, что тесты гораздо менее эффективны согласно результатам мутационного тестирования, чем по результатам голого Code Coverage.

Давайте посмотрим на сгенерированные мутации.

Первая мутация:

class UserFilterAge
{
    const AGE_THRESHOLD = 18;

    public function __invoke(array $collection)
    {
        return array_filter(
            $collection,
            function (array $item) {
-                return $item['age'] >= self::AGE_THRESHOLD;
+                return $item['age'] > self::AGE_THRESHOLD;
            }
        );
    }
}

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

Мутационное тестирование сказало нам, что мы можем взять и заменить условие с ">=" на ">", и программа будет работать точно также. Помните, юнит тесты гарантируют нам, что программа работает так, как мы этого хотим? А раз тесты выполнились успешно с таким мутированным кодом, значит мы и ожидаем такое поведение.

Из этой мутации видно, что, тестируя код с условиями на интервалы, всегда надо проверять граничные значения.

Давайте исправим ситуацию и убьём мутанта:

/**
 * @dataProvider usersProvider
 */
public function test_it_filters_adults(array $users, int $expectedCount)
{
    $filter = new UserFilterAge();

    $this->assertCount($expectedCount, $filter($users));
}

public function usersProvider()
{
    return [
        [
            [
                ['age' => 15],
                ['age' => 20],
            ],
            1
        ],
        [
            [
                ['age' => 18],
            ],
            1
        ]
    ];
}

Мы добавили один тест на граничное значение — 18. Теперь, если опять запустить тесты с мутированным кодом, они упадут, так как все значения отфильтруются и вернется пустая коллекция, что, естественно, неверно.

Вторая мутация:

class UserFilterAge
{
    const AGE_THRESHOLD = 18;

    public function __invoke(array $collection)
    {
-       return array_filter(
+       array_filter(
            $collection,
            function (array $item) {
                return $item['age'] >= self::AGE_THRESHOLD;
            }
        );
+      return null;   
    }
}

Тут не сразу очевидно, что произошло. Это довольно интересный мутационный оператор, заменяющий вызов функции в выражении "return functionCall();" на "functionCall(); return null;".

Но почему вообще произошла такая мутация? Верно ли возвращать null, когда мы ожидаем отфильтрованный массив? Конечно не верно, и происходит это, потому что мы не указали тип возвращаемого значения в функции. МФ видит, что возвращаемое значение может быть null, и пытается подсунуть его. Infection довольно умный в этом плане, и, если функция содержит конкретный тип (не nullable, например int) возвращаемого значения, то мутировать код не будет. Анализируя этого мутанта, приходим к выводу, что надо добавить typehint:

-    public function __invoke(array $collection)
+    public function __invoke(array $collection): array

Теперь сигнатура метода абсолютна понятна — передаем в фильтр массив, ожидаем массив.

Запустим еще раз и проверим результат:

Количество мутаций ожидаемо уменьшилось из-за добавления типа возвращаемого значения, и все мутанты убиты. Теперь мы имеем не только Code Coverage 100%, но и Mutation Code Coverage 100%, что является гораздо более показательным критерием качества ваших тестов.

Этот простой пример показывает, что даже при наличии стопроцентного покрытия кода тестами, мутационное тестирование все еще может выявить проблемы и как бы покрывает ваш код "на более чем 100%".

Если еще не прониклись, рассмотрим мутационные операторы помощнее — PublicVisibility и ProtectedVisibility. Смысл их в том, чтобы для каждого метода класса (кроме некоторых магических и абстрактных) менять модификатор доступа с public на protected, с protected на private.

Это позволяет проверить необходимость открытости методов. Если такие мутанты оказываются выжившими, то можно сделать вывод, что публичный интерфейс вашего класса может быть уменьшен и, скорее всего, является избыточным. А в случае с ProtectedVisibility оператором — выживший мутант говорит о том, что метод должен быть изменен на private и нет ни одного наследника у класса, который бы использовал/переопределял родительский protected метод.

Например, запустив Infection для немалоизвестного FosUserBundle, можно увидеть, что в нем имеется публичный метод isLegacy, открытость которого может быть уменьшена.

./infection.php --threads=4 --show-mutations --mutators=PublicVisibility,ProtectedVisibility

Кроме этих двух случаев с выжившим и убитым мутантом, есть и другие. Например, изменение в цикле унарного оператора "++" у переменной счетчика на "--" может привести к тому, что цикл никогда не закончится, т.к. будет бесконечным. Задача фреймворка для мутационного тестирования — корректно обрабатывать такие ситуцаии и помечать мутанта особым статусом — Timeout. Такой исход является положительным и мутант не считается выжившим.

В целом, с теорией разобрались, теперь посмотрим, что представляет собой Infection более детально, и какие есть еще альтернативы для PHP.

Infection PHP

Для работы, Infection требует установленное расширение xDebug для Code Coverage и PHP 7.0+.

Рекомендуемым способом установки, с возможностью автоматического обновления (infection.phar self-update), является Phar архив.

На данный момент поддерживаются из коробки два фреймворка для тестирования — PHPUnit (5, 6+) и PhpSpec.

При первом запуске из корня вашего проекта будет создан конфиг infection.json.dist, который в последующем можно закоммитить в VCS. В нем указываются папки с исходным кодом для мутации, исключения, значение таймаута и т.д.

Мутационное тестирование в целом требует человеческого анализа, поэтому все сгенерированные мутации после завершения работы МФ попадают в лог файл в той же папке — infection-log.txt.

Опции

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

`--threads`

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

`--show-mutations`

Сразу выводит diff с неубитыми мутантами на консоль, что позволяет моментально анализировать результат и исправлять тест при его написании.

`--mutators`

Перечисление мутационных операторов, мутирующих код. Удобно, если вы например хотите проверить только PublicVisibility и ProtectedVisibility операторы.

./infection.phar --mutators=PublicVisibility,ProtectedVisibility

`--min-msi` и `--min-covered-msi`

Эти две опции полезны, если вы запускаете Infection как один из шагов процесса сборки вашего проекта на Continious Integration сервере.

--min-msi позволяет указать минимальное значение (в процентах) Mutation Score Indicator. Если указанное значение будет меньше фактического, то билд упадет. Данная опция заставляет при каждом билде покрывать большее количество строк кода.

--min-covered-msi соответственно позволяет указать минимальное значение Covered Code MSI. Данная опция при каждом билде заставляет писать более эффективные и надежные тесты.

Обе опции могут использоваться как по отдельности, так и вместе.

./infection.phar --min-msi=80 --min-covered-msi=95

Использование с Travis CI

before_script:
    - wget https://github.com/infection/infection/releases/download/0.5.0/infection.phar
    - wget https://github.com/infection/infection/releases/download/0.5.0/infection.phar.pubkey
    - chmod +x infection.phar
script:
    - ./infection.phar --min-covered-msi=90 --threads=4

Каждый релиз (Phar архив) подписывается приватным openssl ключом, поэтому кроме самого архива вам необходимо скачивать и публичный ключ.

Как использовать мутационное тестирование?

Чем может быть полезно мутационное тестирование вам, как разработчику в ваших рабочих или персональных проектах? Как внедрить его в уже имеющийся проект?

Ежедневное использование для разработчика

Мутационное тестирование может быть полезно в ежедневной работе при написании новых тестов. Схема работы выглядит примерно так:

вы написали новый функционал, например тот же UserFilterAge из примера выше
этот код уже покрыт тестами
для проверки тестов, вы запускаете мутационное тестирование только для этого файла

./infection.phar --threads=4 --filter=UserFilterAge.php --show-mutations

Анализируете выжившие мутанты и пытаетесь добиться хорошего показателя Covered Code MSI — т.е. чтобы процент убитых мутантов из всех сгенерированных для покрытого тестами кода стремился к 100. Это позволит максимально эффективно писать тесты.

При использовании МТ вы заметите, что пишите более лаконичный код с большим количеством тестов. При этом будет использовано покрытие путей (branch coverage), когда все пути вашего кода протестированы, вместо обычного покрытия строк кода (line coverage).

Ежедневное использование в проекте

Мутационное тестирование может быть использовано на Continious Integration сервере. В зависимости от величины проекта, запускать его можно либо при каждом билде, либо реже, как вариант раз в сутки ночью. Тут главное анализировать полученный результат и постоянно улучшать качество тестов.

На мой взгляд, генерируя лишь только отчет, хороших показателей не добиться, поэтому лучше использовать опции --min-msi и/или --min-covered-msi.

Например, мутационный фреймворк Infection мутационно тестирует сам себя при каждом билде. И если показатели падают, билд тоже падает.

При постоянном использовании МТ, показатели MSI в проекте будут расти и вы сможете постепенно увеличивать значения опций --min-msi и --min-covered-msi.

Почему иногда невозможно добиться 100% MSI?

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

public function calculateExpectedValueAt(DateTimeInterface $date)
{
    $diffInDays = (int) $this->startedAt->diff($date)->format('%a');

    $multiplier = $this->initialValue < $this->targetValue ? 1 : -1;
    $initialAveragePerDay = $this->calculateInitialAveragePerDay();

-    return $this->initialValue + ($initialAveragePerDay * $diffInDays * $multiplier);
+    return $this->initialValue + ($initialAveragePerDay * $diffInDays / $multiplier);
}

Смысл в том, что умножение числа и деление числа на ±1 приводит к идентичному результату, и такой мутант оказывается выжившим.

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

Альтернативы для PHP

Единственной полноценной работающей альтернативой для Infection в PHP является Humbug — это вообще первый МФ в PHP. Из плюсов, в нем есть экспериментальная поддержка кеширования мутаций (incremental cache). То есть если какой-то файл не меняется и при этом никакие тесты, покрывающие его строки не удалялись при очередном запуске, то мутация не запускается и берется результат последнего запуска. Теоретически, это может значительно увеличить скорость работы, но может привести к ложным срабатываниям и погрешностям в метриках.

С другой стороны, Humbug пока что не поддерживает PHPUnit 6+ и PhpSpec. Однако, главным отличием между Infection и Humbug на текущий момент является то, что Infection использует абстрактное синтаксическое дерево для мутирования кода (Abstract Syntax Tree (AST)). Построение AST возможно благодaря замечательному проекту Никиты Попова — PHP-Parser.

Что же дает использование AST? Рассмотрим подробнее.

Чтобы начать мутировать код, необходимо

разбить код файла на токены (функция token_get_all()), сложить их в массив
пробежаться по массиву и каждый токен, если это необходимо, заменить на другой, согласно мутационному оператору
из нового набора токенов собрать новый мутированный исходный код

Пример токенов

T_OPEN_TAG ('<?php ')
T_BOOLEAN_AND ('&&')
T_INC ('++')
T_WHITESPACE (' ')
...

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

Находимся ли мы в теле функции? Заменять T_OPEN_TAG ('<?php ') нет никакого смысла
Будет ли валидным код после мутации? (например, сложение массивов ['a'] + ['b'] — это валидный код. А вот вычитание массивов ['a'] - ['b'] — это уже Fatal Error. Следовательно такую мутацию делать не нужно, и МФ должен проверять, не находится ли токен сложения между массивами.

В результате, используя массив токенов, ответить на эти вопросы довольно затруднительно с точки зрения кода. Напротив, имея абстрактное синтаксическое дерево, это легко сделать, оперируя объектами, представляющими исходным код (Node\Expr\BinaryOp\Plus, Node\Expr\BinaryOp\Minus, Node\Expr\Array_).

Вот как выглядят реализации мутационного оператора, меняющего "+" на "-" с проверкой массивов:

Infection

class Plus implements Mutator
{
    public function mutate(Node $node)
    {
        return new BinaryOp\Minus($node->left, $node->right, $node->getAttributes());
    }

    public function shouldMutate(Node $node) : bool
    {
        if (!($node instanceof BinaryOp\Plus)) {
            return false;
        }

        if ($node->left instanceof Array_ && $node->right instanceof Array_) {
            return false;
        }

        return true;
    }
}

Humbug

class Addition extends MutatorAbstract
{
    public static function getMutation(array &$tokens, $index)
    {
        $tokens[$index] = '-';
    }

    public static function mutates(array &$tokens, $index)
    {
        $t = $tokens[$index];
        if (!is_array($t) && $t == '+') {
            $tokenCount = count($tokens);
            for ($i = $index + 1; $i < $tokenCount; $i++) {
                // check for short array syntax
                if (!is_array($tokens[$i]) && $tokens[$i][0] == '[') {
                    return false;
                }
                // check for long array syntax
                if (is_array($tokens[$i]) && $tokens[$i][0] == T_ARRAY && $tokens[$i][1] == 'array') {
                    return false;
                }
                // if we're at the end of the array
                // and we didn't see any array, we
                // can probably mutate this addition
                if (!is_array($tokens[$i]) && $tokens[$i] == ';') {
                    return true;
                }
            }
            return true;
        }
        return false;
    }
}

Очевидно, что использование AST дает огромные преимущества. С ним легче работать, проще поддерживать и разбираться в коде, проще создавать новые мутационные операторы и проще анализировать код, ходя по веткам дерева.

В общем, мутационное тестирование — это еще одно средство для повышения качества ваших тестов и кода в целом, стоящее обращения внимания.

Если у вас есть опыт использования МТ на реальных проектах, или вы попробуете Infection и найдете интересные ошибки в коде — делитесь в комментариях о любых полезных кейсах.

Используемая литература:

Электронная книга по мутационному тестированию (на английском языке)
Mutation Testing Repository

Мутационное тестирование +56

Mutation Score Indicator (MSI)

Mutation Code Coverage

Covered Code Mutation Score Indicator

Infection PHP

Опции

--threads

--show-mutations

--mutators

--min-msi и --min-covered-msi

Использование с Travis CI

Как использовать мутационное тестирование?

Ежедневное использование для разработчика

Ежедневное использование в проекте

Почему иногда невозможно добиться 100% MSI?

Альтернативы для PHP

Комментарии (36)

`--threads`

`--show-mutations`

`--mutators`

`--min-msi` и `--min-covered-msi`