5 основных советов по модульному тестированию Angular

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

Хотя модульное тестирование во всех фронтенд-фреймворках имеет одни и те же основные принципы, неудивительно, что модульное тестирование в Angular имеет некоторые ключевые отличия. Юнит-тестирование — это навык, для развития которого требуется время и терпение. Если вы учитесь писать модульные тесты в Angular, вот 5 основных советов, которые ускорят ваше обучение: понимайте зависимости Angular, тестируйте в изоляции, пишите гранулированные тесты, тестируйте логику, а не DOM, и пишите тесты до кода реализации.

Понимание зависимостей и модулей Angular

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

Архитектура модулей Angular немного уникальна, и, вероятно, это одна из самых сложных частей для новичков. Модули Angular построены поверх модулей ES — решения для совместного использования кода между файлами. По своей сути модуль — это просто способ импорта и экспорта кода для использования другими файлами. Существуют различия в том, как работают модули ES и модули Angular, но основная идея остается неизменной.

Модули Angular Modules перечисляют зависимости, которые может использовать другой код (компоненты, сервисы и т.д.). Например, для того чтобы использовать в приложении многократно используемый компонент кнопки, он должен быть зарегистрирован в соответствующем модуле Angular Module. Если это не так, компилятор выдаст ошибку.
Почему это важно? Это подводит нас ко второму совету.

Тестируйте в изоляции

Тестирование в изоляции означает, что тестируемый модуль должен быть отделен от других частей приложения. Что это значит, когда мы говорим о модульном тестировании в Angular? Что бы вы ни тестировали (будь то компонент, сервис, труба и т.д.), все остальные зависимости должны быть отделены/замоделированы. Если вдуматься, в этом есть смысл.

Мы не хотим тестировать все приложение, мы хотим тестировать только определенный его фрагмент. В этом весь смысл модульного тестирования!

Если вы не будете тестировать изолированно, то в итоге получите многочасовую головную боль, когда будете продираться сквозь неоднозначные ошибки консоли, пытаясь понять, почему (и где!) ваши тесты не работают.

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

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

Пишите подробные модульные тесты

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

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

Для получения дополнительной информации о том, что делает модульный тест Angular ценным, щелкните здесь.

Тестируйте логику, а не DOM

Этот совет может быть немного спорным. Можно писать модульные тесты, которые ищут элементы в DOM, выполняют действие (например, щелчок) и утверждают, что определенное поведение было выполнено.
Хотя я считаю, что некоторые ситуации требуют такой структуры, это не должно быть нормой. Если в своих тестах вы пишете множество запросов к DOM, возможно, вам стоит делегировать эти задачи тесту End-to-End (E2E).

Рассмотрим классический пример с калькулятором, который содержит множество кнопок, выполняющих различные математические операции. Каждый раз, когда нажимается кнопка, происходит манипуляция с данными, и на экране появляется новое число или сумма. Это идеальный сценарий для модульного тестирования! Данные меняются с каждым нажатием кнопки; калькулятор выдает определенный результат, когда ему подаются определенные данные.

С другой стороны, нередко кнопка переводит пользователя на другую страницу или заставляет что-то другое появиться или исчезнуть. Эти сценарии не просто изменяют данные, а представляют функциональность приложения и являются отличной возможностью для написания E2E-теста.

Сначала тест, потом код (разработка, управляемая тестами)

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

Написание тестовых примеров первым называется Test Driven Development (TDD). Вместо того чтобы код реализации влиял на написание модульного теста, TDD позволяет тестовому сценарию определять реализацию кода. Благодаря этому код, написанный по схеме TDD, обычно чище и менее раздутый.

У Test Driven Development есть несколько правил и конвенций, которые идут в комплекте с ней. Если вы хотите узнать больше о TDD, BrowserStack предлагает подробное объяснение.

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

Заключение

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

Я надеюсь, что благодаря пониманию зависимостей Angular, тестированию в изоляции, написанию гранулированных тест-кейсов, тестированию логики, а не DOM, и применению Test Driven Development, у вас будет лучший набор инструментов для успешного ускорения обучения и навыков, необходимых для написания тестов, обеспечивающих уверенность в том, что ваш код ведет себя так, как ожидается.

Оцените статью
Procodings.ru
Добавить комментарий