И почему вас это должно волновать.
При компонентном тестировании вы тестируете более ранние этапы процесса разработки, и вместо тестирования всего приложения (или его большого фрагмента) вы тестируете более мелкие части приложения. С точки зрения Shift Left это очень важно.

Я объясняю это тестированием на примере «лего».

Lego — это строительные блоки, которые разработчики пишут для создания приложения с нуля. И каждая деталь Lego поставляется с одним или несколькими unit-тестами. Но иногда нам нужны на Lego тесты компонентов. Это может вам показаться непонятным. И я задавал следующие вопросы:

1. В чем разница между unit-тестом и компонентным тестом?

2. Кто отвечает за написание компонентных тестов?

3. Если мы используем компонентные тесты, нужны ли нам unit-тесты?

В чем разница между unit-тестом и компонентным тестом

Unit может быть что угодно. Это может быть функция или подпрограмма, и это может быть даже компонент, если его можно протестировать как изолированный фрагмент исходного кода, выполняющий определенную функцию. Когда мы говорим о модульном тестировании функции или подпрограммы, понятно, что мы имеем в виду. Но когда речь идет о модулях для элементов интерфейса, все становится размытым. Давайте сосредоточимся на модульном тестировании front-end-компонента.

Раскрываем компонент

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

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

Unit-тест — это технический тест

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

Компонентный тест — это функциональный тест

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

Но выглядит он как технический тест. Вы должны смонтировать компонент в браузер с необходимыми зависимостями. Конечно, вы тестируете функциональность, но нужно помнить, некоторые технические вещи, такие как стили CSS и поведение DOM. И вам нужно будет знать его точное поведение, и его зависимости. Требуются ли для него вызовы API? Нужно ли его замокать? Или вам нужно использовать его в Shadow DOM?

Кто должен писать компонентные тесты

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

Но если вы, как и я, QA, который любит технические задачи и не боится кода, вам следует этим заняться.

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

Что думают разработчики

Разработчики должны быть заинтересованны. При любом подходе Shift Left тестирование становится более техническим, в результате чего тестировщики и разработчики тесно сотрудничают и помогают друг другу. Это приводит к меньшему количеству ошибок, более высокому качеству и, что не менее важно, к лучшим и более здоровым рабочим отношениям.

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

Нужны ли нам unit-тесты и компонентные тесты

Между unit-тестом и компонентным тестом есть принципиальная разница. Но из-за разницы в области видимости может быть полезно написать и то и другое.

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

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

Вот что такое Shift Left: вместе создавать лучшее ПО.

Присоединяйтесь в наше небольшое сообщество.