Мыслетрекер

Молодость сферы тестирования приводит к тому, что многие термины различными людьми, организациями, книгами, статьями трактуются по-разному.
Модульное, компонентное и unit-тестирование — наглядный пример этой неразберихи.
«Да какая разница, как что называть, главное — правильно использовать!» — можете обоснованно сказать вы. Да! Именно так! Но чтобы знать, как что-то использовать, необходимо и знать о наличии такой техники, и иметь возможность найти краткий инструктаж.
Если в вашем проекте требуется (или полезно, или жизненно необходимо, или «было бы неплохо») модульное или компонентное тестирование, а вы никогда с ним не сталкивались, то вероятность найти подходящую информацию минимальна.
И самое страшное: осознать необходимость в использовании того или иного подхода, заранее о нём не зная, невозможно!

Я часто цитирую Абрахама Маслоу:
«Если в вашем распоряжении есть только молоток, то любая проблема покажется гвоздём».

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

Давайте разберёмся, что такое модульное, компонентное и юнит-тестирование?
Глоссарий ISTQB даёт нам следующие определения:
Модульное тестирование (module testing, unit testing): см. компонентное тестирование
Компонентное тестирование (component testing): тестирование отдельных компонентов программного обеспечения (согласно IEEE 610)
Компонент (component): Наименьший элемент программного обеспечения, который может быть протестирован отдельно.

Выводы, которые можно сделать из этого глоссария: компонентное, модульное и unit тестирование — одно и то же. Так ли это?

Если попытаться найти определения словам «компонент» и «модуль» (а главное, отличия между ними), вы рискуете сойти с ума. Главным принципом компонентно-ориентированного программирования называют модульность, а Component diagram в UML чаще всего переводят как диаграммы модулей.

Общие понятия компонентно-ориентированного программирование изложены на вики, там же можно почитать про модульность.

Нас же будет интересовать более общее определение слов:

Компонент — (от лат. componens, родительный падеж componentis — составляющий), составная часть, элемент чего-либо.

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

Давайте на основании него введём определение компонентного тестирования: это тестирование составных частей программного комплекса по отдельности, изолированно.

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

При этом, компоненты всех уровней «общаются» между собой. Способы общения можно назвать интерфейсами, а взаимодействие компонентов — интеграцией.

Какие возможны «языки» для общения, интерфейсы? Это могут быть записи в БД, вызовы сервисов с различными параметрами, API, и даже файлики. Через XML-формат различные RSS-клиенты собирают информацию по множеству заданных источников — хороший пример интеграции независимых приложений.

А зачем вся эта ботва нужна ручному тестировщику?
Здесь начинается самое интересное. И вправду, как и когда нам нужно использовать компонентное тестирование?

Use-case #1: Затяжная разработка
Продукт начали разрабатывать в марте, а выйти в релиз планируется в сентябре. Первые сборки для тестирования появились в июле, но были неработоспособными. К августу появилась более-менее стабильная сборка, к сентябрю было заведено полтысячи дефектов. Руководство бегает в панике, разработчики пытаются вспомнить, что они там накодили в апреле, а тестировщики возмущаются плохому качеству. Хотя, вместо ковыряния в носу с марта по июль, они уже могли начать компонентное тестирование.

А как, если я не разработчик?
На самом деле, если вы хоть немного разработчик, то решение задачи компонентного тестирования пойдёт значительно лучше. Но если знаний не хватает, то всегда можно договориться с разработчиками об обеспечении testability отдельным компонентам: к примеру, создать простенький интерфейс, GUI или через cmd.

Use-case #2: Локализация дефектов
Все уже поняли, что «ничего не работает» — ещё не баг. Нужна конкретика Она нужна и для принятия решения, что с дефектом делать, и для исправления. Но уровень конкретики может быть разный. К примеру, есть программный продукт, работающий под Windows. Его пользовательский интерфейс сохраняет настройки в реестр windows, а ядро, исходя из настроек, ведёт себя по-разному. И вот, мы поставили настройку, а ожидаемого эффекта не достигли. В этом случае ядро и интерфейс можно называть разными компонентами, интеграция которых происходит через реестр. Давайте посмотрим в реестре, проставился ли там требуемый параметр? Если нет, то ошибка в интерфейсе, если да — то не работает ядро. Этот небольшой кусочек информации сэкономит разработчикам массу времени: РМ сразу будет знать, на кого назначать дефект.

Use-case #3: Всем выйти из сумрака!
Зачастую пользователь через интерфейс не может сделать весь функционал, который реализован в продукте. Если где-то «внутри» есть баги, это ещё не баги продукта (пользователь столкнуться с ними не может). Но это повышенный риск их возникновения: в любой момент ограничения в UI будут сняты, и пользователь «поймает» ошибку.

Посмотрим простой пример: у нас на сайте есть форма регистрации, сохраняющая данные о пользователе в БД. После этого эти данные обрабатываются множеством компонентов системы. В форме регистрации есть ограничения на какие-либо поля, и мы не можем ввести больше, чем n символов. Зато, мы можем ввести их напрямую в БД, если её структура позволяет. Как поведёт себя система в этом случае? Записать данные в БД и проверить работу отдельных компонентов бывает особенно полезно, если поставщиком информации является не часть нашей системы, а какое-либо внешнее приложение.

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

Ну и последнее:
А что тогда такое unit-тестирование?
Это, пожалуй, единственный термин, который обзавёлся общепринятым значением. Юнит-тестами называют проверки отдельных классов нашего приложения, и это техника белого ящика. Так как классы тоже попадают под определение «составная часть, элемент чего-либо», то можно сказать, что юнит-тестирование — это разновидность компонентного тестирования, чаще всего выполняемая (а ещё точнее — чаще всего НЕ выполняемая) разработчиками.