Использование библиотеки Jest

Вступление

Недавно я начал пытаться добавлять тесты в свои проекты, чтобы понять, как они работают, и убедиться, что мои функции возвращают то, чем они должны быть. На моем пути к тому, чтобы узнать больше о том, как реализовать тестирование, я обнаружил среду тестирования Jest.

Начиная

Чтобы начать работу с Jest, вам необходимо убедиться, что он сохранен как зависимость в вашем package.json. Если в вашем проекте еще нет package.json файла, запустите в терминале:

npm init -y

Это инициализирует package.json значениями по умолчанию.

Отсюда мы собираемся добавить Jest в наш package.json. В вашем терминале напишите:

npm i --save-dev jest

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

Теперь войдите в этот package.json и в "scripts", где написано "tests", напишите: "jest".

Чтобы проверить, работает ли он, запустите: npm test

Вы должны увидеть, что написано «Тест не пройден», но это потому, что мы не написали никаких тестов или кода для тестирования.

Давайте добавим код и напишем наши тесты

Я уже пошел дальше и создал файл с именем testing_file.js. В этом файле у меня есть две функции с именами map и cubeAll.

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

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

Затем мы создадим наш тестовый файл. Назовем это testing_file.test.js.

Мы импортируем наши функции в новый тестовый файл.

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

Jest имеет встроенную функцию test и принимает два аргумента: описание теста и функцию. Мы увидим описание теста в консоли, и оно сообщит нам, какой тест выполняется.

Второй аргумент - это то, что вызывается для запуска теста. Внутри этой функции мы вызовем функцию cubeAll с ее параметрами. В Jest есть ключевые слова, которые мы будем использовать внутри нашей функции под названием expect и.toStrictEqual. Поскольку мы работаем с массивами, я буду использовать .toStrictEqual, но в зависимости от того, что вы тестируете, этот сопоставитель может быть другим. Просмотрите документацию в Jest, чтобы узнать, какие сопоставители вам следует использовать.

Позвольте мне объяснить синтаксис, если это выглядит немного запутанным.

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

Одна строка 5, я ожидаю, что результат функцииcubeAll с переданным в параметре [1,2,3] значением будет строго равен [1,8,27].

(вы можете ввести в качестве параметра все, что хотите. Я только что написал [1,2,3])

Мой второй тест ожидает, что результирующий массив будет той же длины, что и три.

Теперь запустим npm test.

Как видите, мои тесты прошли, и мы можем видеть в консоли, какие именно тесты прошли.

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

Мы ясно видим, какие тесты не прошли, и зеленым цветом будет показан ожидаемый результат, а красным - фактический результат. Мой массив должен был быть равен [1,8,27], но вместо этого он вернул [1,4,9].

Почему мы пишем тесты?

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

Например, что, если я случайно напишу внутриcubeAll functionn * n вместо n ** 3. Что ж, когда я написал свой тест «должен возвращать массив этих чисел в кубе», он потерпит неудачу, и тогда я смогу увидеть, какой ожидаемый результат был против того, что я фактически получил.

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

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

Заключение

Надеюсь, это было полезным введением в то, как начать писать собственные тесты. Посетите Библиотеку Jest для получения дополнительной информации.

JavaScript на простом английском языке

Понравилась эта статья? Если да, то получите больше похожего контента, подписавшись на наш канал на YouTube в Decoded!