Стоит ли проводить модульное тестирование компонентов React?

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

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

1. Бизнес-логика

Представьте себе следующий сценарий. Функция X во внешнем модуле отвечает за множество логических операций, которые проходят модульное тестирование. React компонент Y вызывает функцию X внутри условия, и если true отображает компонент A или если false ничего не отображает.

Теперь решение не отображать ничего вместо неисправного компонента A, вероятно, является важным для бизнеса, также известным как Business Logic. Бизнес-логика, безусловно, должна быть рассмотрена в модульных тестах, последнее, что кому-либо нужно, — это чтобы веб-сайт показывал неисправный компонент.

2. Функциональная реакция

React — очень функциональная библиотека. Представления — это функции, а Элементы — простые старые объекты JavaScript (POJO). Мы можем связать их вместе, перебирать их, делать всевозможные вещи, которые мы обычно делаем с функцией, потому что это то, чем они являются. Если вышесказанное верно, то зачем относиться к ним иначе, чем к обычному модулю Javascript? Вообще нет причин. В качестве модулей вы хотите, чтобы они были изолированными / расширяемыми / повторно используемыми. Модульные тесты помогают в этом в огромной степени.

См. также:  Разделитель строк / разрыв в Discord.js встраивать сообщение

На самом деле пользовательского интерфейса больше нет. Ваш компонент «представляет» пользовательский интерфейс, но на самом деле он просто принимает ввод, преобразует его и возвращает. Мы имеем дело с деревьями данных и позволяем React обрабатывать DOM.

3. Моментальные тесты не заменяют

Моментальные тесты — это то, что приобрело популярность в последнее время. Я совсем не против них, но я твердо уверен, что они предназначены для регрессионного тестирования и должны «дополнять», а не «заменять» модульные тесты. Вот мои мысли:

  • Они не могут тестировать такой же уровень детализации, как модульные тесты. Если я изменю часть кода Компонента A, тест, ищущий логику, может завершиться неудачно, даже если он не связан.
  • SRP — каждый тест должен изолировать одно поведение, и в случае неудачи должно быть очевидно, почему
  • Ошибки обнаруживаются как побочные эффекты снимка состояния, они могут не быть связаны с его спецификацией.
  • Детали тестируемого поведения скрыты внутри снимка.
  • Если они выходят из строя (будучи хрупкими), их можно просто воссоздать. Фактически не исправлено.
  • Легко получить рассинхронизацию снимка и теста. Тогда это становится бесполезным.
  • Очень сложно подтвердить тест. Рецензент должен прочитать сгенерированный файл, чтобы узнать, честна ли спецификация теста, а не читать утверждение.
  • В зависимости от теста легко сгенерировать избыточное количество разметки / кода.

Это только мои личные мысли о том, почему они делают плохую замену модульного теста.

4. В любом случае нам не нужно 100% покрытие.

Это распространенное заблуждение и оправдание отсутствия модульных тестов.

На самом деле правда в том, что 0–50% — самая сложная часть. Это где настройка / время / усилия и стоимость. Следующие 50–80% не займут так много времени, как только вы окажетесь на этой стадии. Я часто стремлюсь к 50% и заканчиваю тем, что добавляю больше, поскольку на этом этапе действительно требуется всего пара минут.

См. также:  Javascript: литерал объекта против JSON

5. Этот интерфейс часто меняется.

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

6. У нас есть тесты более высокого уровня, которые их покрывают.

E2E / тесты поведения и т. Д. Не предназначены для охвата всех ветвей так же, как модульные тесты. Если при взаимодействии с пользователем возникает много логики, другие типы тестов не смогут это уловить.

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

Спасибо за чтение, и я хотел бы услышать ваши мысли и впечатления.

Понравилась статья? Поделиться с друзьями:
IT Шеф
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: