Хорошо, вы баловались веб-разработками, делали несколько проектов здесь и там, развернули несколько приложений, которые помогли вам понять основные концепции Front-End разработки, от маршрутизации, рендеринга на стороне сервера, управления состоянием до асинхронных запросов и т. Д.

Но есть одна вещь, которую вы не применили на практике, либо потому, что вы добровольно избегали ее, либо просто потому, что не видели ее пользы: тестирование. В частности, модульное тестирование Front-End - одна очень важная часть экосистемы тестирования.

Модульное тестирование? 🧐

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

По сути, тестирование Front-End кода можно разделить на 3 категории:

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

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

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

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

Пример модульного теста ⚙️

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

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

Я очень рекомендую Jest, поскольку он обычно используется в большинстве проектов и поддерживается отличной командой инженеров Facebook. Обратите внимание, что я буду использовать этот фреймворк в своих примерах.

Я расскажу о нескольких основных примерах модульных тестов, так что давайте перейдем к делу. Если вы хотите продолжить, не стесняйтесь использовать сайт под названием TDDBin.

Давайте разберем код:

  1. Метод, который мы хотим протестировать. Как мы отмечали ранее, модульное тестирование часто применяется к методам или взаимодействиям элементов пользовательского интерфейса. Отличный способ узнать, что тестировать, - это изучить компоненты приложения с нуля. «Что мой метод принимает на вход и каков его результат?», «Влияет ли мой метод на состояние моего компонента?», «Каковы крайние случаи?» это хорошие вопросы, чтобы найти отправную точку.
  2. Набор тестов, который следует кратко описать и сгруппировать связанные модульные тесты. Например, набор тестов может включать все тесты, относящиеся к определенному методу. Вы можете объявить столько наборов тестов, сколько захотите, его основная роль - сделать ваши журналы тестов более читабельными.
  3. Модульный тест, сопровождаемый описанием, оператор (я) внутри обратного вызова является самим тестом.
  4. Тестовое утверждение. Тестирование - это утверждения, сравнение заданного значения с ожидаемым. Здесь мы передаем возвращаемое значение нашего метода add с 1 и 1 в качестве параметров и ожидаем, что результатом будет 2.

Другие тесты, которые мы могли бы добавить

Вот еще несколько тестов, которые было бы разумно добавить для этого примера:

Отрицательные результаты тестирования:

Тестирование обработки ошибок нашего метода (когда в качестве параметра передается что-либо, кроме числа):

Примечание: вы могли видеть, что мы использовали toThrow (), а не toBe (). Jest предлагает множество сопоставителей, чтобы проверить, соответствует ли значение заданному результату. Таким образом, вы можете проверить, является ли значение нулевым, истинным, большим или меньшим и т. Д.

Конкретный пример модульного тестирования 🧪

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

Я создал проект с помощью create-react-app, которое поставляется сразу после настройки Jest. Независимо от того, какой фреймворк вы используете, большинство их интерфейсов командной строки настраивают Jest для вас, так что остается лишь создать ваши тестовые файлы и написать свои тесты! Если вы не используете один из этих интерфейсов командной строки или вам просто нужно настроить Jest с нуля, не стесняйтесь читать их документацию по началу работы.

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

Давайте проследим их вводную документацию, установив необходимые пакеты:

npm i — save-dev enzyme enzyme-adapter-react-16 react-test-renderer

Затем нам нужно настроить наш адаптер, создав следующий файл:

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

Вы могли заметить, что приложение create-response-app создает следующий модульный тест:

Все тестовые файлы имеют похожий формат: * .spec.js или * .test.js в зависимости от ваших предпочтений. Лично я всегда использую первый формат. 😄

Попробуйте, запустив в консоли npm run test. Вы должны получить следующий результат:

Отлично, мы запустили наш первый модульный тест.

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

Наш компонент выглядит так:

Итак, с чего мы начнем? Спросите себя, какие аспекты компонента мы могли бы протестировать в данном случае:

  • Что изначально отображается на экране
  • Что счетчик увеличивается, когда пользователь нажимает кнопку

Тестирование отображаемых значений

Синтаксис Enzyme, подобный JQuery, и утверждения Jest позволяют очень легко протестировать эти случаи. Вот как мы должны это делать:

Вы, наверное, заметили пару вещей, поэтому давайте рассмотрим код.

  1. Как мы упоминали ранее, Jest позволяет нам создавать наборы тестов для организации наших тестов.
  2. Иногда вы хотите настроить что-то перед запуском теста или обернуть другие вещи после того, как они это сделают. Вот почему Jest предлагает вспомогательные функции по настройке и демонтажу, о которых вы можете прочитать здесь. Основные из них, которые вы будете использовать, - это beforeEach и beforeAll, поскольку они позволяют визуализировать ваши компоненты, что подводит нас к третьему пункту.
  3. Неглубокий рендеринг - один из немногих методов рендеринга, которые предлагает Enzyme. В случае неглубокой визуализации мы визуализируем сам компонент без его дочерних элементов. Это позволяет вам тестировать компонент как единое целое, так что если вы измените дочерний элемент, это не повлияет на текущий тестируемый компонент. Рассматривайте рендеринг Enzyme как экземпляр вашего компонента, когда он впервые появляется на вашем экране, с его внутренними состояниями, HTML и всем остальным.
  4. Наш первый тест прост: мы ищем заголовок h1 компонента, передавая селектор методу find, и получаем прямой доступ к его тексту; Затем мы проверяем, используя методы утверждения Jest, что оно содержит значение 0. Все просто, не так ли?

Хорошо, приступим ко второму тесту.

Тестовые мероприятия

Благодаря Enzyme тестирование событий стало очень простым. Вот как мы проверяем, что нажатие на нашу кнопку увеличивает наш счетчик:

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

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

Проверка покрытия кода

Важная концепция, которую нужно понять, - это покрытие кода, оно представляет собой процентную долю вашего кода, который тестируется.

Инструменты покрытия кода проверяют следующее:

  • Заявления: сколько операторов вашего кода выполнено.
  • Ветви: ветки, созданные условными операторами (if / else), которые могут или не могут быть выполнены.
  • Функции: количество вызванных функций.
  • Строки: доля строк, выполненных во время тестов.

И может выглядеть примерно так (на основе нашего предыдущего примера):

Один из наиболее часто используемых инструментов покрытия кода у нас называется Istanbul и используется приложением create-response-app для отчета о покрытии кода вашего приложения, когда вы запускаете следующую команду npm run test - охват.

Такие инструменты, как Istanbul, создают отчет о покрытии кода в виде файлов HTML, которые могут помочь вам получить представление о том, какие части вашего кода не были протестированы. Он выделяет конкретные строки, не охваченные во время ваших модульных тестов, чтобы помочь вам достичь этого сладкого 100% покрытия.

Примечание. Покрытие кода - это еще не все, и 100% покрытие не означает, что вы протестировали все сценарии для данного компонента, поэтому вам следует стремиться к нему только тогда, когда это имеет смысл.

Достойные упоминания 👏

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

Заключительные мысли 🎁

Я считаю, что этой информации достаточно для одного знакомства с Front-End тестированием, и она поможет вам узнать много-много вещей о модульном тестировании в целом.

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

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

Если у вас есть какие-либо вопросы, присылайте их мне в Твиттере @christo_kade, и если вам понравился этот пост, подписка на меня будет предупреждать вас всякий раз, когда я загружаю что-нибудь новое!