Home

Автор: Никонов Владислав

Почитываю книжку Искусство Agile-тестирования и наткнулся в ней на такую штуку как "компонентное тестирование" (КТ). Я уже не первый раз натыкаюсь на этот термин, в первый раз я поискал инфу об этом, как то не очень понял и забил. Но с каждой последующей встречей у меня все больше подгорало.

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

Начнем с определений. Самое крутое (тут сарказм), которое я нашел это - "Компонентное тестирование программного обеспечения - это тестирование отдельных компонентов программного обеспечения". Да и вообще, во многих статьях определение пропускается и пишется, что-то вроде "компонентное тестирование это вид тестирования который следует сразу после модульного и до интеграционного". Еще варианты:

• "тип тестирования ПО, при котором тестирование выполняется для каждого отдельного компонента отдельно, без интеграции с другими компонентами"

• "тип тестирования ПО, в ходе которого проверяется функциональность и удобство использования каждого компонента программного продукта до его интеграции с другими компонентами".

Тут интересно уточнение "без интеграции/без связи с др. компонентами", но при этом КТ делиться на два вида: "Тестирование компонентов в малом" и "Тестирование компонентов в целом". И в случае тестирования компонентов в целом, из определения следует, что конкретный компонент тестируется с помощью других компонентов продукта.

И вот вам еще на вентилятор, во всех источниках мелькает фраза "компонентное тестирование также называют модульным". Хотя мы уже слышали, что КТ выполняется после модульного.

Собственно все эти противоречия порождают следующие вопросы:

1. Почему возникло противоречие - КТ называют модульным тестированием (МТ), но при этом оно выполняется после модульного?

2. В чем разница модульного теста от теста компонента?

3. Все мы "знаем", что МТ это зона ответственности разработчика, тогда почему КТ это зона ответственности тестировщика, если КТ называют МТ?

4. КТ выполняется до интеграционного (ИТ), тогда почему при "тестировании компонентов в целом", участвуют другие компоненты?

Давайте разбираться. Естественно, все что я пишу, это мое субъективное понимание происходящего, буду рад критике, ибо, как фанат Сократа, хочу познать истину.

Итак, на мой взгляд проблема кроется в путанице понятий. Обычно когда мы говорим о МТ, то подразумеваем unit-тесты. Но в основе моей логики лежит следующее утверждение

"Любой unit тест является модульным тестом, но не любой модульный тест является unit тестом".

Говоря про разделение видов тестирования по уровню, мы попадаем в удивительный мир абстракции. Модулем может являться как метод или функция, так и компонент или подпрограмма, главное чтобы его можно было протестировать изолированно. Даже в великой ISTQB, модуль могут назвать компонентом и наоборот. То есть мы видим, что в МТ существуют оба понятия "модуль" и "компонент", и в зависимости от абстракции иногда одно является другим, а значит КТ все-таки можно отнести к МТ. 

Собственно, это и есть ответ на первый вопрос: "Вопрос поставлен некорректно. Правильнее сказать - Компонентное тестирование является модульным тестированием и выполняется после unit тестирования, так как оба понятия "модуль" и "компонент" существуют на уровне модульного тестирования"

Теперь, когда мы преисполнились познанием, становится понятно, что второй вопрос некорректный. Правильнее спросить "В чем разница unit-теста и теста компонента?". Помимо субъективного выделения, которое зависит от архитектурных решений, атомарности и фиг знает еще чего, существует различия в тестовых данных, которые использует тест. В одной статье было сказано "разница в том, что в КТ в качестве параметров функций используют реальные объекты, а в unit тестировании - конкретные значения". Как я это понимаю:

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

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

Мы разобрались с различием unit теста и компонентного теста, а значит можем порассуждать на тему третьего вопроса. У разработчиков от предыдущего абзаца наверное возникнет возмущение, чтото наподобие - "что значит бизнес данные это зона тестировщика?? а как тогда разработчик впринципе проектирует систему не имея представления о бизнес данных?". Ребят, да понятное дело, что разработчики всегда прекрасно знают с какими данными их приложение будет работать и что им придет на вход и что будет на выходе. Просто потому что сами зачастую проектирует структуру этих данных. Вопрос ведь только в подходе, разработчик часто смотрит на эти данные "технически", а QA для того и нужны, чтобы поставить себя на место пользователя/системы/сервиса, который является потребителем разрабатываемого ПО с позиции бизнес кейсов - собственно это и есть ответ на ваши возмущения. 

Итак, unit тест - это технический тест, а тест компонента - функциональный тест. Если рассуждать так, то вроде вполне логично, что за тесты компонентов должны отвечать тестировщики. Юрий Чернов в книге так и обозначает зоны ответственности. Но я с этим не согласен с точки зрения компетенций тестировщика. Модульное тестирование - это про изоляцию, а значит нужны либо замоканые данные, либо драйверы. Это не тривиальная задача для QA. Выше мы рассмотрели пример ближе к бэковой части, но ведь у фронтенд разработчиков тоже есть МТ, а значит есть и КТ. Тут выделять компоненты мне кажется чуть проще, ну чем вам какая-нибудь отдельная форма не компонент. А отдельное поле, вполне себе модуль. Но на сколько часто QA клепают какие-то тесты на уровне модульного тестирования? С проверками именно корректной работы формы, как отдельной сущности в контексте DOM веб страницы. Напоминаю, это уровень МТ, данные тут изолированы. Это не совсем те ui тесты, которые вы привыкли клепать на Cypress/Selenide. 

В общем, на мой взгляд, разработчики полностью занимаются уровнем МТ: 

• потому что никто не задумывается о разнице модуля и компонента и просто смешивают эти виды тестов, т.к. это субъективная абстракция;

• никто не задумывается о разнице происхождения входных данных: технические они или бизнес объекты;

• разработчики лучше ориентируются в коде и им быстрее покрыть код тестами и замокировать тестовые данные на уровне МТ;

• далеко не каждый QA вывезет эту задачу, хоть это и еще одна возможность, для Shift left подхода.

Ну а ответ на четвертый вопрос, вы уже сами поняли - так как это МТ, то используются драйверы и заглушки. Это код имитирующий работу смежных компонентов. Например, функциональная последовательность работы компонентов следующая: получение данных -> приведение данных к нужному виду -> работа с данными. Мы проводим КТ третьего компонента. Используя "тестирование компонентов в целом" мы просто замокаем работу второго компонента, от которого тестируемый компонент получает данные.

Собственно, так я понял "компонентное тестирование". А вот список статей, которые я почитал:

• В чем разница между unit и компонентным тестированием (Habr)

• Компонентное тестирование (QARocks)

• Модульное/юнит/компонентное тестирование (Module/Unit/Component testing) (QABible)

Вот тут можно указать мне на мою тупость и рассказать как правильно.

Обсудить в форуме