Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

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

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

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

4 Для этого понадобятся моки. Они проверяют, как выполняется код.

5 <h2>HTTP</h2>

6 Начнем с такого фрагмента кода:

7 Отслеживание выполнения какого-то действия - это и естьмокинг. Мок проверяет, что какой-то код выполнился определенным образом. Это может быть вызов функции, HTTP-запрос и тому подобное.

8 У мока две задачи:

9 <ul><li>Убедиться в том, что событие произошло - например, функция передала данные</li>

10 <li>Отследить, каким конкретно образом оно произошло - функция передала конкретные данные</li>

11 </ul>Что дает нам такая проверка? В этом случае не очень много. Да, мы убеждаемся, что вызов был, но само по себе это еще ни о чем не говорит. В чем же тогда польза моков?

12 Представьте, что мы бы разрабатывали библиотеку PyGithub - ту самую, что выполняет запросы к GitHub API. Вся суть этой библиотеки в том, чтобы выполнить правильные запросы с правильными параметрами. Поэтому там нужно обязательно проверять выполнение запросов с указанием точных URL-адресов. Только в таком случае можно быть уверенными, что она выполняет верные запросы.

13 В этом ключевое отличие мока от стаба:

14 <ul><li>Стаб устраняет побочный эффект, чтобы не мешать проверке результата работы кода - например, возврату данных из функции</li>

15 <li>Мок фокусируется на том, как конкретно работает код, что он делает внутри</li>

16 </ul>При этом чисто технически мок и стаб создаются почти одинаково, за исключением того, что на мок вешают ожидания, проверяющие вызовы. Из-за этого моками часто называют стабы. Для себя всегда пытайтесь понять, о чем идет речь. Это важно, потому что от этого зависит фокус тестов.

17 <h2>Функции</h2>

18 Моки довольно часто используют с функциями (методами). К примеру, они могут проверять:

19 <ul><li>Вызвана ли функция, сколько раз ее вызвали</li>

20 <li>Какие аргументы переданы в функцию, сколько всего аргументов</li>

21 <li>Что именно вернула функция</li>

22 </ul>Предположим, что мы хотим протестировать функцию for_each(). Она вызывает колбек для каждого элемента коллекции:

23 Эта функция ничего не возвращает, поэтому напрямую ее не протестировать.

24 Можно попробовать сделать это с помощью моков. Проверим, что она вызывает переданный колбек и передает туда нужные значения. Сделаем это с помощью модуляmock, который входит в стандартную библиотеку Python как частьunittest:

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

26 Можно сказать, что этот тест действительно проверяет работоспособность функции for_each(). Но можно сделать это проще, без мока и без завязки на внутреннее поведение. Для этого достаточно использовать замыкание:

27 <h2>Объекты</h2>

28 Кроме использования моков для тестирования функций, они также могут использоваться для тестирования объектов.

29 В тестировании объектов моки могут использоваться для имитации поведения объектов, от которых зависит тестируемый объект. Например, если объект A зависит от объекта B, то можно создать мок-объект для объекта B и использовать его в тестах объекта A. Это позволит тестировать объект A, не затрагивая объект B и его зависимости.

30 Еще он умеет оборачивать существующую реализацию:

31 <h2>Преимущества и недостатки</h2>

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

33 Повсеместное использование моков приводит к двум вещам:

34 <ul><li>После рефакторинга приходится переписывать тесты, даже если код работает правильно. Так происходит, потому что тесты завязаны на то, как конкретно работает код</li>

35 <li>Код может перестать работать. При этом тесты будут проходить, потому что они сфокусированы не на результатах работы кода, а на его устройстве внутри</li>

36 </ul>Там, где возможно использование реального кода - используйте реальный. Там, где возможно убедиться в работе кода без моков - делайте это без моков.

37 Излишний мокинг повышает стоимость поддержки тестов и делает их бесполезными. Идеальные тесты - тесты методом черного ящика.