В тестировании очень популярен "мокинг". Технически он похож на стабинг, и из-за этого их часто путают (специально или ненамеренно). Но всё же они служат разным целям и используются в разных ситуациях. Разберёмся, что это такое, и когда он нужен.
До этого момента мы рассматривали побочные эффекты, как помеху тестирования нашей логики. Для их изоляции использовались стабы, либо прямое выключение логики в тестовой среде. После этого можно было спокойно проверять правильность работы функции.
В некоторых ситуациях требуется кое-что другое. Не результат работы функции, а то, что она выполняет нужное нам действие, например, шлёт правильный HTTP-запрос с правильными параметрами. Для этого понадобятся моки. Моки проверяют, как выполняется код.
HTTP
<?php
class GithubTest extends TestCase
{
public function testGetForkedRepositories(): void
{
$mock = $this->createMock(\Github\Client::class);
// Указываем что метод api() возвращает саму заглушку
$mock->method('api')
->willReturn($this->returnSelf());
// Ожидаем что метод api вызовется один раз с параметром 'hexlet'
$mock->expects($this->once())
->method('api')
->with($this->equalTo('hexlet'));
$org = 'hexlet';
$forks = getForkedRepositories($org, $mock);
}
}
Это и называется мокинг. Мок проверяет, что какой-то код выполнился определённым образом. Это может быть вызов функции, HTTP-запрос и тому подобное. Задача мока убедиться в том, что это произошло, и в том, как конкретно это произошло, например, что в функцию были переданы конкретные данные.
Что даёт нам такая проверка? В данном случае мало что. Да, мы убеждаемся, что вызов был, но само по себе это ещё ни о чём не говорит. Так когда же полезны моки?
Представьте, что мы бы разрабатывали библиотеку KnpLabs/php-github-api, ту самую, что выполняет запросы к GitHub API. Вся суть этой библиотеки в том, чтобы выполнить правильные запросы с правильными параметрами. Поэтому там нужно обязательно проверять выполнение запросов с указанием точных URL-адресов. Только в таком случае можно быть уверенными, что она выполняет верные запросы.
В этом ключевое отличие мока от стаба. Стаб устраняет побочный эффект, чтобы не мешать проверке результата работы кода, например, возврату данных из функции. Мок фокусируется на том, как конкретно работает код, что он делает внутри. При этом чисто технически мок и стаб создаются одинаково, за исключением того, что на мок вешают ожидания, проверяющие вызовы. Это приводит к путанице, потому что часто моками называют стабы. С этим ничего уже не поделать, но для себя всегда пытайтесь понять, о чём идет речь. Это важно, от этого зависит фокус тестов.
Преимущества и недостатки
Несмотря на то, что существуют ситуации, в которых моки нужны, в большинстве ситуаций их нужно избегать. Моки слишком много знают о том, как работает код. Любой тест с моками из чёрного ящика превращается в белый ящик. Повсеместное использование моков приводит к двум вещам:
- После рефакторинга приходится переписывать тесты (много тестов!), даже если код работает правильно. Происходит это из-за завязки на то, как конкретно работает код.
- Код может перестать работать, но тесты проходят, потому что они сфокусированы не на результатах его работы, а на том, как он устроен внутри.
Там, где возможно использование реального кода, используйте реальный. Там, где возможно убедиться в работе кода без моков, делайте это без моков. Излишний мокинг делает тесты бесполезными, а стоимость их поддержки высокой. Идеальные тесты – тесты методом чёрного ящика.
Дополнительные материалы
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
Для полного доступа к курсу нужен базовый план
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.
