Режимом watch тестового фреймворка jest

Обновлено: 07.07.2024

Утилита командной строки jest имеет ряд полезных опций. Вы можете выполнить команду jest --help для просмотра всех доступных параметров. Многие из них могут использоваться совместно друг с другом для запуска тестов именно так, как вы хотите. Всем конфигурационным параметрам также соответствуют опции для командной строки.

Вот их краткий обзор:

Запуск всех тестов (по умолчанию):

Запустить только тесты по шаблону или по имени файла:

Выполнить тесты, связанные с измененными файлами, отраженными в hg/git (uncommitted файлы):

Запуск тестов, относящихся к файлам path/to/fileA.js и path/to/fileB.js :

Run tests that match this spec name (match against the name in describe or test , basically).

Запуск в режиме отслеживания изменений:

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

Если Jest запускается через npm test , по-прежнему можно использовать аргументы командной строки путем добавления -- между командой npm test и аргументами Jest. Вместо:

вы можете использовать:

Аргументы командной строки имеют приоритет над значениями из конфигурации.

При запуске Jest с аргументом этот аргумент интерпретируется как регулярное выражение, сопоставляемое c файлами в вашем проекте. Это позволяет запустить наборы тестов, предоставляя шаблон. Будут выбраны и выполнены только те файлы, которые соответствуют шаблону. Примечание: в зависимости от вашего терминала, может потребоваться экранирование аргумента кавычками: jest "довольно.* (сложный)? шаблон" .

Псевдоним: -b . Завершает выполнение тестов сразу же после первого сбоя.

Нужно ли использовать кэш. По умолчанию используется значение true. Отключить использование кэша можно с помощью флага --no-cache . Примечание: кэш следует отключать, только если вы испытываете связанные с ним трудности. В среднем, отключение кэша делает Jest по крайней мере в два раза медленнее.

If you want to inspect or clear the cache, use --showConfig and look at the cacheDirectory value.

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

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

Принудительно включает подсветку вывода результатов тестирования, даже если stdout – не TTY.

Псевдоним: -c . Путь к файлу конфигурации Jest, указывающий, как находить и выполнять тесты. Если параметр rootDir не задан в конфигурации, предполагается, что текущий каталог – корневой в проекте. Для задания данной опции может быть использовано JSON-значение, которое Jest будет использовать как конфигурацию.

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

Печатает отладочную информацию о вашей конфигурации Jest.

Тестовое окружение, используемое для всех тестов. Может указывать на любой node-модуль или файл. Примеры: jsdom , node или путь/к/окружению.js .

Находит и запускает тесты, совпадающие со списком исходных файлов, переданных в качестве аргументов. Может быть полезно в pre-commit хуках системы контроля версий для запуска минимального необходимого множества тестов.

Вынуждает Jest закончить исполнение после того, как все тесты завершены. Полезно в случаях, когда ресурсы, созданные в целях тестирования, не могут быть освобождены надлежащим образом. Примечание: Данная опция – это, по сути, обходной механизм. Если Jest не заканчивает выполнение после того, как тесты завершились, это означает, что внешние ресурсы по-прежнему удерживаются или таймеры ожидают завершения. Настоятельно рекомендуется высвобождать внешние ресурсы после завершения каждого отдельного теста для того, чтобы Jest успешно мог завершить выполнение.

Показать справку, схожую с данной страницей.

Записывает результаты тестов в файл, если также указан флаг --json .

Выполнит все тесты, затрагиваемые изменениями файлов в последнем коммите.

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

Заносит в журнал данные об использовании динамической области после каждого теста. Полезно для выявления утечек памяти. При запуске в Node используйте вместе с опциями --runInBand и --expose-gc .

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

Отключает отображение трассирования стека при выводе результатов тестов.

Активирует уведомления для результатов тестирования. Хорошо, когда вы не хотите акцентировать все свое внимание на тестировании JavaScript.

Псевдоним: -o . Предпринимает попытку определить какие тесты запускать основываясь на данных о том, какие файлы в текущем репозитории были изменены. Успешно срабатывает только если вы запускаете тесты в git/hg репозитории. Также требует наличия статического графа зависимостей (т. е. не динамические зависимости).

Run tests from one or more projects.

Псевдоним: -i . Последовательно выполняет все тесты в текущем процессе вместо создания пула дочерних рабочих процессов, которые выполняют тесты. Может быть полезно для отладки.

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

Выводит конфигурацию Jest и затем завершается.

Псевдоним: -t . Запускает только те тесты, имя которых совпадает с регулярным выражением.

Строка регулярного выражения, которая противопоставляется всем путям тестов перед выполнением.

Позволяет указать сторонний исполнитель тестов.

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

Переадресует все выходные данные в stderr.

Отображает результаты индивидуальных тестов в тестовой иерархии.

Псевдоним: -v . Печатает текущую версию и выходит.

Наблюдает за изменениями в файлах и перезапускает тесты связанные с измененными файлами. Если вместо этого необходимо перезапускать все тесты, используйте флаг --watchAll .

Наблюдает за изменениями в файлах и перезапускает тесты, если что-то изменяется. Если необходимо перезапускать только тесты для измененных файлов, используйте флаг --watch .

Следует ли использовать watchman для обхода файлов. По умолчанию используется значение true. Возможно отключить используя --no-watchman .

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

A typical snapshot test case renders a UI component, takes a snapshot, then compares it to a reference snapshot file stored alongside the test. The test will fail if the two snapshots do not match: either the change is unexpected, or the reference snapshot needs to be updated to the new version of the UI component.

Похожий подход может быть использован, когда дело доходит до тестирования React компонентов. Вместо отображения графического пользовательского интерфейса, что потребует сборки всего приложения, разработчик может использовать специализированный модуль для генерации сериализуемого значения для конкретного React дерева. Consider this example test for a Link component:

The first time this test is run, Jest creates a snapshot file that looks like this:

Более подробную информацию о том как тестирование с использованием снимков работает и почему мы ее реализовали можно найти в данной записи нашего блога. Ме рекомендуем ознакомиться со следующей записью, чтобы получить хорошее представление о том, когда использовать тестирование с использованием снимков. We also recommend watching this egghead video on Snapshot Testing with Jest.

Если был введен баг, то довольно просто обнаружить тест со снимком, который проваливается. Когда такое происходит, устраните проблему и убедитесь, что ваши тесты завершаются успешно. А теперь давайте поговорим о случае, когда тест проваливается по причине осознанных изменений в реализации.

Подобная ситуация може возникнуть если мы намеренно внесем изменения в адрес ссылки внутри компонента Link в нашем примере.

// Updated test case with a Link to a different address

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

Чтобы решить эту проблему, нам нужно будет обновить сохраненный снимок. Вы можете запустить Jest с флагом, который укажет на необходимость повторной генерации снимков:

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

You can try out this functionality by cloning the snapshot example, modifying the Link component, and running Jest.

Failed snapshots can also be updated interactively in watch mode:

Once you enter Interactive Snapshot Mode, Jest will step you through the failed snapshots one test at a time and give you the opportunity to review the failed output.

From here you can choose to update that snapshot or skip to the next:

Inline snapshots behave identically to external snapshots ( .snap files), except the snapshot values are written automatically back into the source code. This means you can get the benefits of automatically generated snapshots without having to switch to an external file to make sure the correct value was written.

Пример:

First, you write a test, calling .toMatchInlineSnapshot() with no arguments:

The next time you run Jest, tree will be evaluated, and a snapshot will be written as an argument to toMatchInlineSnapshot :

Often there are fields in the object you want to snapshot which are generated (like IDs and Dates). If you try to snapshot these objects, they will force the snapshot to fail on every run:

For these cases, Jest allows providing an asymmetric matcher for any property. These matchers are checked before the snapshot is written or tested, and then saved to the snapshot file instead of the received value:

Any given value that is not a matcher will be checked exactly and saved to the snapshot:

Snapshots are a fantastic tool for identifying unexpected interface changes within your application – whether that interface is an API response, UI, logs, or error messages. As with any testing strategy, there are some best-practices you should be aware of, and guidelines you should follow, in order to use them effectively.

Commit snapshots and review them as part of your regular code review process. This means treating snapshots as you would any other type of test or code in your project.

Ensure that your snapshots are readable by keeping them focused, short, and by using tools that enforce these stylistic conventions.

As mentioned previously, Jest uses pretty-format to make snapshots human-readable, but you may find it useful to introduce additional tools, like eslint-plugin-jest with its no-large-snapshots option, or snapshot-diff with its component snapshot comparison feature, to promote committing short, focused assertions.

The goal is to make it easy to review snapshots in pull requests, and fight against the habit of regenerating snapshots when test suites fail instead of examining the root causes of their failure.

Ваши тесты должны быть детерминированными. Running the same tests multiple times on a component that has not changed should produce the same results every time. Вы ответственны за убеждение в том, что сохраненные снимки не включают специфичные для платформы или любые другие недетерминированные данные.

For example, if you have a Clock component that uses Date.now() , the snapshot generated from this component will be different every time the test case is run. В этом случае мы можем создать мок для метода Date.now(), чтобы возвращать фиксированное значение при каждом запуске теста:

Теперь при каждом запуске теста, Date.now() будет постоянно возвращать значение 1482363367071 . Это приведет к тому, что для данного компонента будет создаваться один и тот же снимок независимо от того, когда тест запускается.

Always strive to use descriptive test and/or snapshot names for snapshots. The best names describe the expected snapshot content. This makes it easier for reviewers to verify the snapshots during review, and for anyone to know whether or not an outdated snapshot is the correct behavior before updating.

exports [ ` <UserName /> should handle some test case ` ] = ` null ` ; exports [ ` <UserName /> should handle some other test case ` ] = ` exports [ ` <UserName /> should render Alan Turing ` ] = ` null ` ;

No, as of Jest 20, snapshots in Jest are not automatically written when Jest is run in a CI system without explicitly passing --updateSnapshot . Ожидается, что снимки являются обязательной частью теста, выполняемого на CI, следовательно, если они отсутствуют, тест не должен проходить. Рекомендуется всегда включать снимки в коммит вместе с тестами и хранить в системе контроля версий.

Yes, all snapshot files should be committed alongside the modules they are covering and their tests. They should be considered part of a test, similar to the value of any other assertion in Jest. In fact, snapshots represent the state of the source modules at any given point in time. In this way, when the source modules are modified, Jest can tell what changed from the previous version. It can also provide a lot of additional context during code review in which reviewers can study your changes better.

Snapshot testing and visual regression testing are two distinct ways of testing UIs, and they serve different purposes. Visual regression testing tools take screenshots of web pages and compare the resulting images pixel by pixel. With Snapshot testing values are serialized, stored within text files, and compared using a diff algorithm. There are different trade-offs to consider and we listed the reasons why snapshot testing was built in the Jest blog.

Snapshot testing is only one of more than 20 assertions that ship with Jest. The aim of snapshot testing is not to replace existing unit tests, but to provide additional value and make testing painless. In some scenarios, snapshot testing can potentially remove the need for unit testing for a particular set of functionalities (e.g. React components), but they can work together as well.

Jest has been rewritten with performance in mind, and snapshot testing is not an exception. Since snapshots are stored within text files, this way of testing is fast and reliable. Jest generates a new file for each test file that invokes the toMatchSnapshot matcher. The size of the snapshots is pretty small: For reference, the size of all snapshot files in the Jest codebase itself is less than 300 KB.

Snapshot files must always represent the current state of the modules they are covering. Таким образом, если вы объединяете две ветки и сталкиваетесь с конфликтом в снимках файлов, вы можете разрешить конфликт вручную или обновить файл снимка, запустив Jest и просмотрев результат.

Although it is possible to write snapshot files manually, that is usually not approachable. Снимки скорее помогают определить, изменен ли код модулей, покрытых тестами, чем подсказывают как его проектировать.

Утилита командной строки jest имеет ряд полезных опций. Вы можете выполнить команду jest --help для просмотра всех доступных параметров. Многие из них могут использоваться совместно друг с другом для запуска тестов именно так, как вы хотите. Каждый из конфигурационных параметров Jest может также быть настроен через командную строку.

Вот их краткий обзор:

Запуск всех тестов (по умолчанию):

Запустить только тесты по шаблону или по имени файла:

Выполнить тесты, связанные с измененными файлами, отраженными в hg/git (uncommitted файлы):

Запуск тестов, относящихся к файлам path/to/fileA.js и path/to/fileB.js :

Выполнить тесты, названия которых совпадают с переданным аргументом (сравниваются строки в блоках describe и test ).

Запуск в режиме отслеживания изменений:

Если вы запустите Jest через yarn test , вы можете передать аргументы командной строки прямо как Jest аргументы.

вы можете использовать:

Если вы запускаете Jest с помощью npm test , то вы по-прежнему можете использовать аргументы командной строки путем добавления -- между командой npm test и аргументами Jest.

вы можете использовать:

Jest поддерживает форматы написания аргументов в верблюжьем стиле (camelCase) и через тире. Следующие примеры будут иметь одинаковый результат:

Формат написания аргументов может смешиваться:

На заметку: аргументы коммандной строки имеют приоритет над значениям в файле Configuration.

При запуске Jest с аргументом этот аргумент интерпретируется как регулярное выражение, сопоставляемое c файлами в вашем проекте. Это позволяет запустить наборы тестов, предоставляя шаблон. Будут выбраны и выполнены только те файлы, которые соответствуют шаблону. В зависимости от терминала, может понадобится заключить аргумент в кавычки: jest "my.*(complex)?pattern" . On Windows, you will need to use / as a path separator or escape \ as \\ .

Псевдоним: -b . Выход из набора тестов сразу после n неудачных тестов. По умолчанию 1 .

Чтобы посмотреть содержимое кэша используйте аргумент --showConfig и значение cacheDirectory . Для очистки кэша добавьте --clearCache .

Запускает тесты для файлов с текущими изменениями, а также для файлов, которые были измененны в предыдущем коммите. Похожая опция: --onlyChanged .

Запускает тесты, которые затрагивают изменения в указанной ветке или коммите. Если рабочая ветка не совпадает с указанной, тогда будут протестированны только локальные изменения. Похожая опция: --onlyChanged .

Удаляет директорию с кэшом Jest и завершает процесс без запуска тестов. Опция cacheDirectory используется для указания директории с кэшом. Если её пропустить, Jest удалит кэш-директорию по-умолчанию. Чтобы узнать, где находится кэш-директория по умолчанию, вызовите следующую комманду: jest --showConfig . Внимание: очистка кэша снижает производительность!

Glob-шаблон отностительно rootDir , по которому будут выбраны файлы с информацией для отчета о покритии тестами.

Принудительно включает подсветку вывода результатов тестирования, даже если stdout – не TTY.

Псевдоним: -c . Путь к файлу конфигурации Jest, в котором указывается где искать и как выполнять тесты. Если в конфигурации не задан rootDir , тогда каталог с конфигурационным файлом будет считаться rootDir для проекта. Для задания данной опции может быть использовано JSON-значение, которое Jest будет использовать как конфигурацию.

Аналог: --collectCoverage . Указывает, что следует собирать и отображать информацию о тестовом покрытии. Возможно передать <boolean> для переопределения параметров, установленных в конфигурации.

Indicates which provider should be used to instrument code for coverage. Допустимые значения: babel (по умолчанию) или v8 .

Выводит информацию о файле конфигурации Jest.

Attempt to collect and print open handles preventing Jest from exiting cleanly. Use this in cases where you need to use --forceExit in order for Jest to exit to potentially track down the reason. This implies --runInBand , making tests run serially. Реализовано с использованием async_hooks . Эта опция существенно снижает производительность и поэтому рекоммендуется использовать её только при отладке.

Make calling deprecated APIs throw helpful error messages. Useful for easing the upgrade process.

Путь к модулю, экспортирующему функцию фильтрации. This method receives a list of tests which can be manipulated to exclude tests from running. Especially useful when used in conjunction with a testing infrastructure to filter known broken.

Запускает тесты, которые покрывают список файлов, переданных в качестве параметров через пробел. Эту опцию удобно использовать в связке с pre-commit хуком, так как она будет запускать только минимально необходимое количество тестов. Can be used together with --coverage to include a test coverage for the source files, no duplicate --collectCoverageFrom arguments needed.

Показать справку, схожую с данной страницей.

Создание базового файла конфигурации. Jest задаст несколько вопросов, чтобы сгенерировать файл jest.config.js с коротким описанием каждой опции.

Добавить глобальные переменные Jest ( expect , test , describe , beforeEach и т. д.) в окружение. Если эта опция равна false , тогда нужно импортировать глобальные переменные из @jest/globals , например.

Jest - это библиотека для тестирования кода JavaScript. Это проект с открытым исходным кодом, поддерживаемый Facebook, и он особенно хорошо подходит для тестирования кода React, хотя и не ограничивается этим: он может тестировать любой код JavaScript. Jest очень быстрый и простой в использовании

Введение в Jest

Jest - это библиотека для тестирования кода JavaScript.

Это проект с открытым исходным кодом, поддерживаемый Facebook, и он особенно хорошо подходит для тестирования кода React, хотя и не ограничивается этим: он может тестировать любой код JavaScript. Его сильные стороны:

это быстро
он может выполнятьтестирование снимков
он самоуверен и предоставляет все "из коробки", не требуя от вас делать выбор

Jest - это инструмент, очень похожий на Mocha, хотя у них есть отличия:

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

На мой взгляд, самая большая особенность Jest - это готовое решение, которое работает без необходимости взаимодействия с другими библиотеками тестирования для выполнения своей работы.

Установка

Jest автоматически устанавливается в create-react-app , поэтому, если вы его используете, вам не нужно устанавливать Jest.

Jest можно установить в любом другом проекте, используяПряжа:

обратите внимание, как мы приказываем обоим поместить Jest в devDependencies часть package.json файл, так что он будет установлен только в среде разработки, а не в производственной среде.

Добавьте эту строку в часть скриптов вашего package.json файл:

так что тесты можно запускать с помощью yarn test или же npm run test .

В качестве альтернативы вы можете установить Jest глобально:

и запустите все свои тесты, используя jest инструмент командной строки.

Создайте первый тест Jest

Проекты, созданные с create-react-app иметь установленный и предварительно настроенный Jest из коробки, но добавить Jest в любой проект так же просто, как ввести

Добавить в свой package.json эта строка:

и запустите свои тесты, выполнив yarn test в вашей оболочке.

Теперь у вас нет никаких тестов, поэтому ничего не будет выполняться:

Создадим первый тест. Откройте math.js file и введите пару функций, которые мы позже протестируем:

Теперь создайте math.test.js файл в той же папке, и там мы будем использовать Jest для тестирования функций, определенных в math.js :

Бег yarn test приводит к тому, что Jest запускается для всех найденных тестовых файлов и возвращает нам конечный результат:

Запустите Jest с VS Code

Visual Studio Code - отличный редактор для разработки на JavaScript. ВРасширение Jestпредлагает первоклассную интеграцию для наших тестов.

После его установки он автоматически определит, установили ли вы Jest в свои devDependencies, и запустит тесты. Вы также можете вызвать тесты вручную, выбравJest: Start Runnerкоманда. Он будет запускать тесты и оставаться в режиме просмотра, чтобы повторно запускать их всякий раз, когда вы изменяете один из файлов, содержащих тест (или тестовый файл):

Матчеры

В предыдущей статье я использовал toBe() как единственныйсопоставитель:

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

Наиболее часто используемые сопоставители, сравнивающие значение результата expect() со значением, переданным в качестве аргумента, следующие:

toBe сравнивает строгое равенство, используя ===
toEqual сравнивает значения двух переменных. Если это объект или массив, он проверяет равенство всех свойств или элементов.
toBeNull истинно при передаче нулевого значения
toBeDefined истинно при передаче определенного значения (противоположно указанному выше)
toBeUndefined истинно при передаче неопределенного значения
toBeCloseTo используется для сравнения значений с плавающей запятой, избегая ошибок округления
toBeTruthy истина, если значение считается истинным (например, if делает)
toBeFalsy истина, если значение считается ложным (например, if делает)
toBeGreaterThan истина, если результат expect () выше аргумента
toBeGreaterThanOrEqual истина, если результат expect () равен аргументу или больше аргумента
toBeLessThan истина, если результат expect () ниже аргумента
toBeLessThanOrEqual истина, если результат expect () равен аргументу или меньше аргумента
toMatch используется для сравнения строк срегулярное выражениесопоставление с образцом
toContain используется в массивах, истина, если ожидаемый массив содержит аргумент в его наборе элементов
toHaveLength(number) : проверяет длину массива
toHaveProperty(key, value) : проверяет, есть ли у объекта свойство, и при необходимости проверяет его значение
toThrow проверяет, вызывает ли переданная вами функция исключение (в общем) или конкретное исключение
toBeInstanceOf() : проверяет, является ли объект экземпляром класса

Все эти сопоставители можно отменить, используя .not. внутри оператора, например:

Для использования с обещаниями вы можете использовать .resolves и .rejects :

Настраивать

Перед запуском тестов вы захотите выполнить некоторую инициализацию.

Чтобы сделать что-то один раз перед запуском всех тестов, используйте beforeAll() функция:

Чтобы выполнить что-либо перед каждым запуском теста, используйте beforeEach() :

Срывать

Как и в случае с настройкой, вы также можете выполнять что-то после каждого запуска теста:

и после окончания всех тестов:

Групповые тесты с использованием description ()

Вы можете создавать группы тестов в одном файле, которые изолируют функции настройки и удаления:

Тестирование асинхронного кода

Асинхронный код в современном JavaScript может иметь две формы: обратные вызовы и обещания. Помимо обещаний, мы можем использовать async / await.

Обратные вызовы

Обещания

С функциями, возвращающими обещания, мывернуть обещаниеиз теста:

Отклоненные обещания можно проверить с помощью .catch() :

Асинхронный / ожидание

Для тестирования функций, возвращающих обещания, мы также можем использовать async / await, что делает синтаксис очень простым и понятным:

Издевательство

При тестированиинасмешливыйпозволяет тестировать функциональность, зависящую от:

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

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

Еще важнее, если вы пишетеМодульный тест, вам следует тестировать функциональность функции изолированно, а не со всем набором вещей, которых она касается.

Используя макеты, вы можете проверить, была ли вызвана функция модуля и какие параметры использовались, с помощью:

expect().toHaveBeenCalled() : проверьте, была ли вызвана шпионская функция
expect().toHaveBeenCalledTimes() : подсчитать, сколько раз вызывалась шпионская функция
expect().toHaveBeenCalledWith() : проверить, вызывалась ли функция с определенным набором параметров
expect().toHaveBeenLastCalledWith() : проверить параметры последнего вызова функции

Шпионские пакеты, не влияющие на код функций

Когда вы импортируете пакет, вы можете указать Jest «шпионить» за выполнением определенной функции, используя spyOn() , не влияя на то, как этот метод работает.

Имитация всего пакета

Jest предоставляет удобный способ имитировать весь пакет. Создать __mocks__ в корне проекта, и в этой папке создайте по одному файлу JavaScript для каждого из ваших пакетов.

Скажите, что вы импортируете mathjs . Создать __mocks__/mathjs.js файл в корне вашего проекта и добавьте это содержимое:

Это будет имитировать функцию пакета log (). Добавьте столько функций, сколько хотите имитировать:

Имитация единственной функции

Вы можете издеваться над одной функцией, используя jest.fn() :

Вы также можете использовать jest.fn().mockReturnValue('test') чтобы создать простой макет, который ничего не делает, кроме возврата значения.

Готовые макеты

Тестирование снимков

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

Это простой тест на компоненте приложения простого create-react-app приложение (убедитесь, что вы установили react-test-renderer ):

при первом запуске этого теста Jest сохраняет снимок в __snapshots__ папка. Вот что содержит App.test.js.snap:

Как видите, это код, который визуализирует компонент приложения, не более того.

Когда используешь yarn test в create-react-app ты врежим часов, и оттуда вы можете нажать w и показать больше вариантов:

Читайте также: