PHPUnit. «Как мне протестировать мой чёртов контроллер», или тестирование для сомневающихся25.01.2020 09:53

2) Чрезмерно переусложнённые примеры. А давайте напишем тест, и запихнём его в Gitlab CI, а потом будем ещё автодеплоить если тест прошёл, а на тесты ещё PHP Infection намажем, да с Hudson всё соеденим. И так далее в таком стиле. Вроде и полезно, а вроде и совсем не то что ты ищешь. А ведь хочется просто чуток увеличить стабильность своего проекта. А все эти непрерывности — ну потом, не всё же сразу…

В итоге люди сомневаются, «а надо ли оно мне». Я же, в свою очередь, хочу попытаться рассказать о тестировании понятнее. И оговорюсь сразу — я разработчик, я не тестировщик. Я уверен, что я сам многого не знаю, а моим первым в жизни словом не было слово «мок». Я даже никогда не работал по TDD! Зато я точно знаю, что даже мой текущий уровень навыков позволил мне покрыть несколько проектов тестами, а эти самые тесты уже отловили свой десяток багов. А если мне это помогло — значит и кому-то ещё может помочь. Некоторые пойманные баги было бы сложно выловить вручную.

Для начала, краткий ликбез в формате вопрос-ответ:

Q: Я обязан использовать какой-то фреймворк? А что если у меня Yii? А если Kohana? А если %one_more_framework_name%?
А: Нет, PHPUnit это самостоятельный фреймворк для тестирования, вы можете его прикрутить хоть к легаси-коду на самопальном фреймворке.

Q: А я сейчас руками сайт по-быстрому прохожу, и нормально. Зачем оно мне?
А: «Прогон» нескольких десятков тестов длится несколько секунд. Автоматическое тестирование всегда быстрее мануального, а при качественных тестах ещё и надёжнее, так как покрывает все сценарии.

Q: У меня легаси-код с функциями по 2000 строк. Я могу это тестировать?
A: И да, и нет. В теории — да, любой код можно покрыть тестом. На практике, код должен писаться с заделом под будущее тестирование. Функция на 2000 строк будет иметь слишком много зависимостей, ветвлений, пограничных случаев. Может и получится её в итоге всю покрыть, но скорее всего это займёт у вас непозволительно много времени. Чем качественнее код — тем легче его тестировать. Чем лучше соблюдается принцип Single Responsibility — тем проще будут тесты. Для тестирования старых проектов чаще всего придётся сначала здорово отрефакторить их.

Q: У меня очень простые методы (функции), что там тестировать? Там всё надёжно, там нет места ошибке!
А: Следует понимать, вы не тестируете правильность реализации функции (если у вас не TDD), вы просто «фиксируете» её текущее состояние работы. В будущем, когда вам понадобится её изменять, вы сможете с помощью теста быстро определять не сломали ли вы её поведение. Пример: есть функция, которая валидирует email. Делает она это регуляркой.

function isValid($email)
{
    $regex = "very_complex_regex_here";

    if (is_array($email)) {
        $result = true;

        foreach ($email as $item) {
            if (preg_match($regex, $item) === 0) {
                $result = false;
            }
        }
    } else {
        $result = preg_match($regex, $emai) ==! 0;
    }

    return $result;
}

Весь ваш код расчитывает на то, что если передать в эту функцию валидный имейл — она вернёт true. Массив валидных имейлов — тоже true. Массив хотя бы с одним невалидным имейлом — false. Ну и так далее, по коду суть понятна. Но настал день, и вы решили заменить монструозную регулярку внешним API. Но как гарантировать, что переписанная функция не поменяла принцип работы? Вдруг она плохо обработает массив? Или вернёт не boolean? А тесты смогут это всё держать под контролем. Хорошо написанный тест сразу укажет на поведение функции отличное от ожидаемого.

Q: Когда я начну видеть толк от тестов?
А: Во-первых, как только покроете значительную часть кода. Чем ближе покрытие к 100% — тем надёжнее тестирование. Во-вторых, как только придётся делать глобальные изменения, либо же изменения в сложной части кода. Тесты могут отловить такие проблемы, которые вручную могут быть легко упущены (пограничные случаи). Во-третьих, при написании самых тестов! Часто возникает ситуация, когда при написании теста выявляются недостатки кода, которые на первый взгляд незаметны.

Q: Ну вот, у меня сайт на laravel. Сайт это не функция, сайт это хренова гора кода. Как тут тестировать?
А: Именно об этом пойдёт речь дальше. Вкратце: отдельно тестируем методы контроллеров, отдельно middleware, отдельно сервисы, и т. д.

Одна из идей Unit-тестирования заключается в изоляции тестируемого участка кода. Чем меньше кода проверяется одним тестом — тем лучше. Посмотрим пример максимально приближённый к реальной жизни:

userService = $userService;
        $this->emailService = $emailService;
    }

    public function login($request)
    {
        if (empty($request->login) || empty($request->password)) {
            return "Auth error";
        }

        $password = $this->userService->getPasswordFor($request->login);

        if (empty($password)) {
            return "Auth error - no password";
        }

        if ($password !== $request->password) {
            return "Incorrect password";
        }

        $this->emailService->sendEmail($request->login);

        return "Success";
    }
}

// ....

/* somewhere in project core */
$controller = new Controller($userService, $emailService);

$controller->login($request);

Это очень типичный метод логина в систему на небольших проектах. Всё что мы ожидаем — это правильные сообщения о ошибках, и отправленный имейл в случае успешного логина. Как же протестировать данный метод? Для начала, надо выявить внешние зависимости. В нашем случае их две — $userService и $emailService. Они передаются через конструктор класса, что здорово облегчает нам задачу. Но, как говорилось ранее, чем меньше кода мы тестим за один проход — тем лучше.

Эмуляция, подмена объектов называется моканьем (от англ. mock object, буквально: «объект-пародия»). Никто не мешает писать такие объекты вручную, но всё уже придумано до нас, поэтому на помощь приходит такая чудесная библиотека как Mockery. Давайте создадим моки для сервисов.

$userService = Mockery::mock('user_service');
$emailService = Mockery::mock('email_service');

Теперь создадим объект $request. Для начала, протестируем логику проверки полей login и password. Мы хотим быть уверенны, что если их не будет — наш метод корректно обработает этот случай, и вернёт нужное (!) сообщение.

function testEmptyLogin()
{
    $userService = Mockery::mock('user_service');
    $emailService = Mockery::mock('email_service');

    $controller = new Controller($userService, $emailService);

    $request = (object) [];

    $result = $controller->login($request);
}

Ничего сложного, не так ли? Мы создали заглушки для необходимых параметров класса, создали экземпляр нужного класса, и «дёрнули» нужный метод, передавая заведомо неправильный запрос. Получили ответ. Но как теперь его проверить? Это и есть самая важная часть теста — так называемое утверждение, assertion. PHPUnit имеет десятки готовых assertions. Просто используем одну из них

function testEmptyLogin()
{
    $userService = Mockery::mock('user_service');
    $emailService = Mockery::mock('email_service');

    $controller = new Controller($userService, $emailService);

    $request = (object) [];

    $result = $controller->login($request);
    
    // vv assertion here! vv
    $this->assertEquals("Auth error", $result);
}

Данный тест гарантирует следующее — если в метод логин прилетит аргумент-объект у которого не найдётся поля login или password — то метод вернёт строку «Auth error». Вот, в общем-то, и всё. Так просто —, но так полезно, ведь теперь мы можем редактировать метод login без страха сломать что-то. Наш frontend может быть уверенным, что в случае чего — он получит именно такую ошибку. И если кто-то сломает это поведение (например, решит изменить текст ошибки) — то тест сразу же об этом просигнализирует! Допишем остальные проверки, чтобы покрыть как можно больше возможных сценариев.

function testEmptyPassword()
{
    $userService = Mockery::mock('user_service');

    // $userService->getPasswordFor(__any__arg__); // ''
    $userService->shouldReceive('getPasswordFor')->andReturn('');

    $emailService = Mockery::mock('email_service');

    $request = (object) [
        'login' => 'john',
        'pass' => '1234'
    ];

    $result = (new Controller($userService, $emailService))->login($request);

    $this->assertEquals("Auth error - no password", $result);
}

function testUncorrectPassword()
{
    $userService = Mockery::mock('user_service');

    // $userService->getPasswordFor(__any__arg__); // '4321'
    $userService->shouldReceive('getPasswordFor')->andReturn('4321');

    $emailService = Mockery::mock('email_service');

    $request = (object) [
        'login' => 'john',
        'pass' => '1234'
    ];

    $result = (new Controller($userService, $emailService))->login($request);

    $this->assertEquals("Incorrect password", $result);
}

function testSuccessfullLogin()
{
    $userService = Mockery::mock('user_service');

    // $userService->getPasswordFor(__any__arg__); // '1234'
    $userService->shouldReceive('getPasswordFor')->andReturn('1234');

    $emailService = Mockery::mock('email_service');

    $request = (object) [
        'login' => 'john',
        'pass' => '1234'
    ];

    $result = (new Controller($userService, $emailService))->login($request);

    $this->assertEquals("Success", $result);
}

Заметили методы shouldReceive и andReturn? Они позволяют нам создавать методы в заглушках, которые вернут только то, что нам надо. Надо протестировать ошибку неправильного пароля? Пишем заглушку $userService которая всегда возвращает неверный пароль. И всё.

А что же по-поводу зависимостей, спросите вы. Их то мы «заглушили», а вдруг они сломаются? А вот именно для этого и надо максимальное покрытие кода тестами. Мы не будем проверять работу этих сервисов в контексте логина — мы будем тестировать логин рассчитывая на правильную работу сервисов. А потом напишем такие же, изолированные тесты для этих сервисов. А потом тесты для их зависимостей. И так далее. В итоге каждый отдельный тест гарантирует только правильную работу маленького куска кода, при условии что все его зависимости работают правильно. А так как все зависимости тоже покрыты тестами — то их правильная работа тоже гарантируется. В итоге, любое изменение в систему ломающее логику работы даже малейшего участка кода — сразу же отобразится в том или ином тесте. Как конкретно запустить прогон тестов — рассказывать не буду, документация у PHPUnit вполне хорошая. А в Laravel, например, достаточно выполнить vendor/bin/phpunit с корня проекта, чтобы увидеть сообщение вроде этого — все тесты прошли успешно. Или вроде этогоОдин из семи assert-ов провалился.

«Это, конечно, классно, но что из этого я не поймаю руками?» — спросите вы. А давайте для этого представим следующий код

getInfo($userName);

    if ($response->status === "API Error") {
        return null;
    }

    return $response->result;
}

// ... somewhere in system

$api = new ExternalApi();

$info = getInfo($api, 'John');

if ($info === null) {
    die('Api is down');
}

echo $info;

Мы видим упрощённую модель работы с внешним API. Функция использует какой-то класс для работы c API, и в случае ошибки — возвращает null. Если же при использовании этой функции мы получаем null — следует «поднять панику» (отправить сообщение в слак, или имейл разработчику, или кинуть ошибку в кибану. Да куча вариантов). Вроде всё просто, не так ли? Но представим что через некоторое время другой разработчик решил «поправить» эту функцию. Он решил что возвращать null — это прошлый век, и следует кидать исключение.

function getInfo($infoApi, $userName): string
{
    $response = $infoApi->getInfo($userName);

    if ($response->status === "API Error") {
        throw new ApiException($response);
    }

    return $response->result;
}

И он даже переписал все участки кода, где вызывалась эта функция! Все, кроме одного. Его он упустил. Отвлёкся, устал, просто ошибся — да мало ли. Факт лишь в том, что один участок кода всё ещё ожидает старого поведения функции. А PHP это у нас не Java — мы не получим ошибку компиляции на основании того, что throwable функция не завёрнута в try-catch. В итоге в одном из 100 сценариев использования сайта, в случае падения API — мы не получим сообщение от системы. Более того, при ручном тестировании мы скорее всего не отловим этот вариант события. API у нас внешнее, от нас не зависит, работает хорошо — и скорее всего мы не попадём «руками» на случай отказа API, и неверной обработки исключения. Зато будь у нас тесты — они отлично отловят данный кейс, потому что класс ExternalApi в ряде тестов у нас «заглушен», и эмулирует как нормальное поведение, так и падение. И следующий тест у нас упадёт

function testApiFail()
{
    $api = Mockery::mock('api');

    $api->shouldReceive('getInfo')->andReturn((object) [
        'status' => 'API Error'
    ]);

    $result = getInfo($api, 'name');

    $this->assertNull($result);
}

Этой информации, на самом деле, достаточно. Если у вас не легаси лапша, уже спустя минут 20–30 вы сможете написать свой первый тест. А спустя несколько недель — узнать что-то новое, крутое, вернуться в комментарии под этот пост, и написать какой автор говнокодер, и не знает о %framework_name%, и тесты хреновые пишет, а надо делать %this_way%. И я буду очень рад в таком случае. Это будет значит что моя цель достигнута: кто-то ещё открыл для себя тестирование, и немножечко повысил общий уровень профессионализма в нашей сфере!

Аргументированная критика приветствуется.

© Habrahabr.ru