Даже если ваши модульные тесты охватывают все и проходят во время сборки, ваше приложение все равно может быть полностью сломано в производственной среде. 🧐🤔

При разработке веб-приложений тестирование имеет решающее значение.
Невозможно создать качественное приложение без надлежащего тестирования.

Итак, сегодня мы поговорим о ТЕСТИРОВАНИИ. Привет, Мик, Тестирование 1,2,3,4… 🎤

Тестируем одним из двух способов:

  • Руководство по эксплуатации
  • Автоматизированный

Ручное тестирование

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

Мы поговорим об автоматическом тестировании 🤖

Автоматизированное тестирование

Существует три различных метода автоматизированного тестирования:

  • Ед. изм
  • Интеграция
  • Концы с концами

Давайте подробнее рассмотрим каждый подход.

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

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

Интеграционное тестирование

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

Сквозное тестирование

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

Вау, теперь мы немного знаем, что означают эти три. 👏

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

В последние несколько лет стали популярны несколько инструментов, в том числе:

Что такое Jest? (с официального сайта)

Jest - это восхитительный фреймворк для тестирования JavaScript с упором на простоту.
Он работает с проектами, использующими: Babel, TypeScript, Node, React, Angular, Vue и другие!

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

Во-первых, давайте посмотрим, как работает Jest. У нас есть модуль под названием sum.js:

Мы можем проверить это с помощью Jest в sum.test.js вот так:

И ничего себе, это пройдет. 👏 Замечательно !!!

Но что произойдет, если мы воспользуемся null или "1":

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

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

И опять же, действительно ли мы знаем, что такое единицы приложения?

Например:

Нам неизвестны значения a и b для функции sum. Они происходят из двух отдельных модулей.

Итак, чтобы выполнить операцию суммирования, нам нужно сделать что-то вроде этого:

Но мы действительно мотивированные разработчики и хотим подготовить модульные тесты для getA и getB, а также для sum, поэтому мы думаем, что у нас есть 100% покрытие модульными тестами.

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

Затем мы думаем о создании функции с именем doEverythingAndReturnSum, которая (как следует из названия) выполняет все и возвращает sum:

Вау круто.
- А что здесь за агрегат?

getA ? getB ? sum? or doEverythingAndReturnSum ? 💭

Если мы теперь протестируем все модули по отдельности и будем счастливы, что наше приложение имеет 100% тестовое покрытие, результат может выглядеть примерно так: 🙈💥

До сих пор мы в основном смотрели на код JavaScript, а не на пользовательский интерфейс. Но, как мы знаем, тестирование пользовательского интерфейса еще сложнее, поскольку задействовано несколько уровней кода:

  • ДОМ
  • стили
  • События
  • Данные, поступающие из удаленных API
  • Браузеры и т. Д.

Когда мы говорим о тестировании пользовательского интерфейса для приложений React, первое, что приходит на ум, - это «Компоненты».

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

Одним из самых популярных инструментов для тестирования компонентов React является Enzyme.

Enzyme - это утилита для тестирования JavaScript для React, которая упрощает тестирование выходных данных компонентов React. Вы также можете манипулировать, перемещаться и некоторым образом моделировать время выполнения на основе выходных данных.

Давайте посмотрим на пример того, как мы можем модульно протестировать компонент с помощью Jest и Enzyme.

У нас есть один компонент с именем MyComponent, и мы передаем ему элемент <div> с классом с именем unique.

Чтобы проверить это, мы утверждаем, что после рендеринга компонент должен включать <div> с классом unique:

Справедливо!

Он проходит, что означает, что у него есть элемент <div> и класс unique.

Но подождите…
- что, если в той же фиксации я полностью разрушу стиль класса unique? Этот тест все равно пройдет. 🤨

Есть еще один способ тестирования компонентов React - тестирование Jest Snapshot. Это еще один механизм модульного тестирования, которого недостаточно. Вы можете прочитать еще один мой пост здесь Тестирование снимков Jest для компонентов React бесполезно? Он медленно умирает? 🧐🤔😐

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

Даже если мы на секунду проигнорируем удаленный API, он все равно не гарантирует этого.

О, еще одна забавная вещь:
- Наше приложение представляет собой веб-приложение, и оно будет работать в браузере (и даже в нескольких браузерах, поскольку мы не знаем, какие браузеры используют буду использовать).

Но мы пока не тестируем компоненты в одном браузере. Как мы можем гарантировать, что он будет корректно работать в разных браузерах?

Давным-давно, в 2015 году (давно, потому что в мире Интернета или JS 2015 год считается древним), Google опубликовал статью о пирамиде тестирования:

Они предложили проводить в основном модульное тестирование, а не сквозное (E2E) тестирование: Просто скажи нет большему количеству сквозных тестов.

Мартин Фаулер поделился своими мыслями о TestPyramid еще раньше, в 2012 году:

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

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

Кент С. Доддс объединил их и придумал следующее:

Потрясающие!

Кроме того, он предложил то, что он называет «Testing Trophy», в котором основное внимание уделяется интеграционному тестированию.

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

Как сказал Гильермо Раух:

Понятие приложение в современной сети быстро меняется. Браузер может намного больше, чем раньше. JavaScript развивается вместе с ESNext. Фактически, время также изменило инструменты тестирования. В настоящее время у нас есть больше инструментов и фреймворков, чтобы лучше выполнять интеграцию и тестирование E2E.

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

А пока,
Ура!

👋