Я очень серьезно отношусь к модульному тестированию. Я считаю, что у этого есть огромные плюсы, и это дисциплина, которой следует придерживаться. Однако недавно я натолкнулся на общее убеждение, которое заключается в следующем:
«Сам пользовательский интерфейс тривиален и требует больших затрат на тестирование, поэтому не стоит прилагать никаких усилий. Вся фактическая логика находится в отдельных служебных модулях, которые тестируются »- я лично с этим категорически не согласен и вот почему.
1. Бизнес-логика
Представьте себе следующий сценарий. Функция X во внешнем модуле отвечает за множество логических операций, которые проходят модульное тестирование. React компонент Y вызывает функцию X внутри условия, и если true отображает компонент A или если false ничего не отображает.
Теперь решение не отображать ничего вместо неисправного компонента A, вероятно, является важным для бизнеса, также известным как Business Logic. Бизнес-логика, безусловно, должна быть рассмотрена в модульных тестах, последнее, что кому-либо нужно, — это чтобы веб-сайт показывал неисправный компонент.
2. Функциональная реакция
React — очень функциональная библиотека. Представления — это функции, а Элементы — простые старые объекты JavaScript (POJO). Мы можем связать их вместе, перебирать их, делать всевозможные вещи, которые мы обычно делаем с функцией, потому что это то, чем они являются. Если вышесказанное верно, то зачем относиться к ним иначе, чем к обычному модулю Javascript? Вообще нет причин. В качестве модулей вы хотите, чтобы они были изолированными / расширяемыми / повторно используемыми. Модульные тесты помогают в этом в огромной степени.
На самом деле пользовательского интерфейса больше нет. Ваш компонент «представляет» пользовательский интерфейс, но на самом деле он просто принимает ввод, преобразует его и возвращает. Мы имеем дело с деревьями данных и позволяем React обрабатывать DOM.
3. Моментальные тесты не заменяют
Моментальные тесты — это то, что приобрело популярность в последнее время. Я совсем не против них, но я твердо уверен, что они предназначены для регрессионного тестирования и должны «дополнять», а не «заменять» модульные тесты. Вот мои мысли:
- Они не могут тестировать такой же уровень детализации, как модульные тесты. Если я изменю часть кода Компонента A, тест, ищущий логику, может завершиться неудачно, даже если он не связан.
- SRP — каждый тест должен изолировать одно поведение, и в случае неудачи должно быть очевидно, почему
- Ошибки обнаруживаются как побочные эффекты снимка состояния, они могут не быть связаны с его спецификацией.
- Детали тестируемого поведения скрыты внутри снимка.
- Если они выходят из строя (будучи хрупкими), их можно просто воссоздать. Фактически не исправлено.
- Легко получить рассинхронизацию снимка и теста. Тогда это становится бесполезным.
- Очень сложно подтвердить тест. Рецензент должен прочитать сгенерированный файл, чтобы узнать, честна ли спецификация теста, а не читать утверждение.
- В зависимости от теста легко сгенерировать избыточное количество разметки / кода.
Это только мои личные мысли о том, почему они делают плохую замену модульного теста.
4. В любом случае нам не нужно 100% покрытие.
Это распространенное заблуждение и оправдание отсутствия модульных тестов.
На самом деле правда в том, что 0–50% — самая сложная часть. Это где настройка / время / усилия и стоимость. Следующие 50–80% не займут так много времени, как только вы окажетесь на этой стадии. Я часто стремлюсь к 50% и заканчиваю тем, что добавляю больше, поскольку на этом этапе действительно требуется всего пара минут.
5. Этот интерфейс часто меняется.
У меня нет проблем с одноразовым кодом, но на самом деле это то, о чем люди должны уже договориться. Если над чем-то собираются работать снова и снова, то это явно не выбрасывание, и это должно быть защищено модульным тестом. Это придаст уверенности и поможет обеспечить соблюдение хороших шаблонов проектирования в этом новом коде.
6. У нас есть тесты более высокого уровня, которые их покрывают.
E2E / тесты поведения и т. Д. Не предназначены для охвата всех ветвей так же, как модульные тесты. Если при взаимодействии с пользователем возникает много логики, другие типы тестов не смогут это уловить.
Я знаю, что это не все причины, и их, несомненно, гораздо больше, но я искренне надеюсь, что их не слишком много.
Спасибо за чтение, и я хотел бы услышать ваши мысли и впечатления.
