2 added
2 removed
Original
2026-01-01
Modified
2026-02-26
1
<p>Большинство тестов на одну и ту же функциональность сильно похожи друг на друга. Особенно в части начальной подготовки данных. В прошлом уроке каждый тест начинался со строчки: makeStack(). Это ещё не дублирование, но уже шаг в эту сторону. Как правило, реальные тесты сложнее и включают в себя большую подготовительную работу.</p>
1
<p>Большинство тестов на одну и ту же функциональность сильно похожи друг на друга. Особенно в части начальной подготовки данных. В прошлом уроке каждый тест начинался со строчки: makeStack(). Это ещё не дублирование, но уже шаг в эту сторону. Как правило, реальные тесты сложнее и включают в себя большую подготовительную работу.</p>
2
<p>Допустим, мы разрабатываем библиотеку<a>Lodash</a>и хотим протестировать её функции для обработки коллекций:</p>
2
<p>Допустим, мы разрабатываем библиотеку<a>Lodash</a>и хотим протестировать её функции для обработки коллекций:</p>
3
<ul><li>find</li>
3
<ul><li>find</li>
4
<li>filter</li>
4
<li>filter</li>
5
<li>includes</li>
5
<li>includes</li>
6
<li>и другие (всего их около 20 штук)</li>
6
<li>и другие (всего их около 20 штук)</li>
7
</ul><p>Для работы этих функций нужна заранее подготовленная коллекция. Проще всего придумать одну, которая подойдёт для тестирования большинства или даже всех функций:</p>
7
</ul><p>Для работы этих функций нужна заранее подготовленная коллекция. Проще всего придумать одну, которая подойдёт для тестирования большинства или даже всех функций:</p>
8
<p>Теперь представьте, что таких тестов несколько десятков (в реальности их сотни). Код начнёт кочевать из одного места в другое, порождая всё больше и больше копипасты.</p>
8
<p>Теперь представьте, что таких тестов несколько десятков (в реальности их сотни). Код начнёт кочевать из одного места в другое, порождая всё больше и больше копипасты.</p>
9
<p>Самый простой способ избежать этого - вынести определение коллекции на уровень модуля, вне тестовых функций:</p>
9
<p>Самый простой способ избежать этого - вынести определение коллекции на уровень модуля, вне тестовых функций:</p>
10
<p>Это простое решение убирает ненужное дублирование. Однако учтите, оно работает только в рамках одного модуля. Подобную коллекцию всё равно придётся определять в каждом тестовом модуле. И в нашем случае это скорее плюс, а не минус.</p>
10
<p>Это простое решение убирает ненужное дублирование. Однако учтите, оно работает только в рамках одного модуля. Подобную коллекцию всё равно придётся определять в каждом тестовом модуле. И в нашем случае это скорее плюс, а не минус.</p>
11
<p>Дело в том, что излишнее обобщение, приводящее к полному устранению дублирования, вводит неявные зависимости в код. Изменение этой коллекции почти наверняка приведёт к поломке большинства тестов, которые завязаны на её структуру, на количество элементов и их значения:</p>
11
<p>Дело в том, что излишнее обобщение, приводящее к полному устранению дублирования, вводит неявные зависимости в код. Изменение этой коллекции почти наверняка приведёт к поломке большинства тестов, которые завязаны на её структуру, на количество элементов и их значения:</p>
12
<p>Тест выше сломается, если мы добавим в нашу коллекцию еще одно чётное число. А коллекцию почти наверняка придётся расширять при добавлении новых тестов (для этой же или других функций).</p>
12
<p>Тест выше сломается, если мы добавим в нашу коллекцию еще одно чётное число. А коллекцию почти наверняка придётся расширять при добавлении новых тестов (для этой же или других функций).</p>
13
<p>Главный вывод из этого: устранять дублирование надо. Но важно не перейти границу, после которой обобщение начинает больше мешать, чем помогать.</p>
13
<p>Главный вывод из этого: устранять дублирование надо. Но важно не перейти границу, после которой обобщение начинает больше мешать, чем помогать.</p>
14
<p>Но далеко не всегда можно выносить константы на уровень модуля. В первую очередь это касается динамических данных. Представьте себе такой код:</p>
14
<p>Но далеко не всегда можно выносить константы на уровень модуля. В первую очередь это касается динамических данных. Представьте себе такой код:</p>
15
<p>Подвох тут в том, что модуль загружается в память ровно один раз. Это значит, что весь код, определённый на уровне модуля (включая константы), выполняется ровно один раз. В примере константа now определится до запуска всех тестов, и только затем<em>jest</em>начнёт выполнять тесты. И с каждым последующим тестом отставание значения константы now от текущего реального значения "сейчас" будет всё дальше и дальше.</p>
15
<p>Подвох тут в том, что модуль загружается в память ровно один раз. Это значит, что весь код, определённый на уровне модуля (включая константы), выполняется ровно один раз. В примере константа now определится до запуска всех тестов, и только затем<em>jest</em>начнёт выполнять тесты. И с каждым последующим тестом отставание значения константы now от текущего реального значения "сейчас" будет всё дальше и дальше.</p>
16
<p>Почему это может быть проблемой? Код, который работает с понятием "сейчас", может рассчитывать на то, что "сейчас" это почти моментальный снимок данного момента времени. Но в примере выше, сейчас начинает отставать от реального сейчас и чем больше тестов и чем они сложнее, тем большее отставание.</p>
16
<p>Почему это может быть проблемой? Код, который работает с понятием "сейчас", может рассчитывать на то, что "сейчас" это почти моментальный снимок данного момента времени. Но в примере выше, сейчас начинает отставать от реального сейчас и чем больше тестов и чем они сложнее, тем большее отставание.</p>
17
<p><em>Важно не забыть: функция test не запускает тест на выполнение. Она добавляет его внутрь Jest, а вот он уже решает, когда выполнить этот тест. Поэтому между загрузкой модуля и отработкой тестов проходит неопределённое время.</em></p>
17
<p><em>Важно не забыть: функция test не запускает тест на выполнение. Она добавляет его внутрь Jest, а вот он уже решает, когда выполнить этот тест. Поэтому между загрузкой модуля и отработкой тестов проходит неопределённое время.</em></p>
18
<p>Для решения этой проблемы тестовые фреймворки предоставляют<strong>хуки</strong>- специальные функции, которые запускаются до или после тестов. Ниже пример того, как создавать дату перед каждым тестом:</p>
18
<p>Для решения этой проблемы тестовые фреймворки предоставляют<strong>хуки</strong>- специальные функции, которые запускаются до или после тестов. Ниже пример того, как создавать дату перед каждым тестом:</p>
19
<p>beforeEach(callback) принимает на вход функцию, внутри которой выполняется инициализирующее действие. Оно не обязательно приводит к созданию переменных. Возможно, инициализация заключается в подготовке файловой системы, например, создании файлов.</p>
19
<p>beforeEach(callback) принимает на вход функцию, внутри которой выполняется инициализирующее действие. Оно не обязательно приводит к созданию переменных. Возможно, инициализация заключается в подготовке файловой системы, например, создании файлов.</p>
20
<p>Но если она должна создать данные и сделать их доступными в тестах, то придётся использовать переменные, определённые на уровне модуля. Так как всё, что определяется внутри функций (колбека в нашем случае), остаётся внутри этой функции.</p>
20
<p>Но если она должна создать данные и сделать их доступными в тестах, то придётся использовать переменные, определённые на уровне модуля. Так как всё, что определяется внутри функций (колбека в нашем случае), остаётся внутри этой функции.</p>
21
<p>Рассмотрим еще один пример:</p>
21
<p>Рассмотрим еще один пример:</p>
22
-
<p>Функция add() изменяет исходный объект по ссылке, добавляя в него ключ со значением. Второй тест не пройдет, так как объект уже содержит значение из предыдущего теста. Чтобы исправить это, нужно возвращать объект к исходному виду перед каждым тестом. Для этого может пригодиться beforeEach():</p>
22
+
<p>Функция add() изменяет исходный объект по ссылке, добавляя в него ключ со значением. Второй тест не пройдет, так как объект уже содержит значение из предыдущего теста. Чтобы исправить это, нужно возвращать объект к исходному виду перед каждым тестом. Для этого мо��ет пригодиться beforeEach():</p>
23
-
<p>Даже если нам нужно выполнить код один раз перед всеми тестами, его все равно нужно выполнять не на уровне модуля, а внутри хука beforeAll(callback). Этот хук запускается ровно один раз перед всеми тестами, р��сположенными в одном модуле.</p>
23
+
<p>Даже если нам нужно выполнить код один раз перед всеми тестами, его все равно нужно выполнять не на уровне модуля, а внутри хука beforeAll(callback). Этот хук запускается ровно один раз перед всеми тестами, расположенными в одном модуле.</p>
24
<p>Почему это важно? Чтобы ответить на этот вопрос, нам нужно знать немного больше про асинхронную природу JavaScript. Этот вопрос разбирается в курсах позже, а пока можно ограничиться вот чем: Jest должен контролировать происходящие процессы и побочные эффекты в тестах. Все, что вызывается на уровне модуля, отрабатывается вне Jest. Это значит, что Jest никак не может отследить, что происходит, и в какой момент можно запускать тесты.</p>
24
<p>Почему это важно? Чтобы ответить на этот вопрос, нам нужно знать немного больше про асинхронную природу JavaScript. Этот вопрос разбирается в курсах позже, а пока можно ограничиться вот чем: Jest должен контролировать происходящие процессы и побочные эффекты в тестах. Все, что вызывается на уровне модуля, отрабатывается вне Jest. Это значит, что Jest никак не может отследить, что происходит, и в какой момент можно запускать тесты.</p>