Представим, что определенное сочетание ветвей выполнения приводит к ошибке. Вы можете ее не выявить, поскольку даже если все ветви покрыты, тесты могли не пройти по тому самому сочетанию путей, из-за которого возникает дефект.
В связи с этим покрытие кода само по себе является плохим показателем. Оно помогает узнать, какие части кода программы покрыты, но ничего не говорит о покрытии возможных вариантов поведения.
Все виды покрытия важны, но обычно больше всего внимания я уделяю покрытию ветвей.
Покрытие ветвей указывает, что в ходе тестирования код прошел все возможные пути выполнения. Это гарантирует, что на каждом разветвлении, когда код должен был «принимать решение», проверялись все возможные варианты.
Кроме того, показатель покрытия кода может говорить о том, что тесты прошли все возможные ветви выполнения, но не перебрали все некорректные значения, которые можно было подать на вход.
Например, если передать этой функции 1 и 0 в качестве первого и второго аргументов, она вернет Infinity, что может быть нежелательным результатом.
Покрытие показывает, какую часть кода покрывают тесты, а не то, сколько возможных входных значений они передают. Следовательно, вы не можете гарантировать выявления всех дефектов, если не проверите весь возможный ввод, а это сделать довольно сложно.
СОВЕТ
Чтобы понять, почему проверка всех возможных входных значений является сложной, если вообще выполнимой, задачей, подумайте о том, сколько разных чисел можно представить в JavaScript.
Если вы, как я и советовал, используете NPM-скрипты для выполнения тестов, отчеты о покрытии можно получить с помощью команды npm test -- --coverage.
Закончив прохождение тестов и сбор данных о частях кода, которые тестами выполняются, Jest создаст в корне проекта папку с именем coverage: в ней будет находиться полный отчет о покрытии.
Наконец, чтобы увидеть, какие участки кода покрыты тестами, откройте в браузере файл index.html из папки lcov-
Обращая внимание на покрытие кода тестами, вы сможете обнаружить «слепые зоны» в своем тестовом наборе и сделать тестирование более тщательным.
ВАЖНО
Зная, какие части кода покрываются тестами, а какие — нет (что более важно), вы можете проследить за тем, чтобы во время процесса автоматизированного тестирования проверялись все ветви выполнения.
идеальных условиях у нас было бы время для написания сразу двух тестов: одного с проверкой дублера, другого — без проверки. Но в реальном мире приходится выбирать тот тест, который принесет больше пользы и потребует минимального количества времени и усилий.
В подобной ситуации не следует проверять, записывает ли knex товары в базу данных, — этим должны заниматься авторы библиотеки.
У вас есть два варианта: а) заменить knex тестовым дублером и проверить, вызывается ли тот корректно; б) запустить тестовую базу данных, вызвать createCart и проверить, была ли записана строка так, как вы того ожидали.
Ни в одном из случаев вы не тестируете сам модуль knex. Всегда уделяйте первоочередное внимание своему взаимодействию с библиотекой. Тестирование чужих библиотек — пустая трата усилий: почти всегда это приводит к написанию тестов, которые уже были написаны кем-то другим.
В этом разделе вы видели уже несколько разных способов создания тестовых дублеров. Чтобы понять, какому из них отдать предпочтение, подумайте о том, что именно вы пытаетесь макетировать.
Если вы макетируете свойство объекта, вам, вероятно, лучше использовать jest.spyOn.
Если вы макетируете операцию импорта, подойдет, скорее всего, jest.mock.
