Лучшее обеспечение качества: изучение стандартов модульного тестирования

Что такое модульное тестирование

Модульное тестирование (Unit Testing) - это тип тестирования программного обеспечения, при котором тестируются отдельные модули или компоненты программного обеспечения. Его цель заключается в том, чтобы проверить, что каждая единица программного кода работает должным образом. Данный вид тестирование выполняется разработчиками на этапе кодирования приложения. Модульные тесты изолируют часть кода и проверяют его работоспособность. Единицей для измерения может служить отдельная функция, метод, процедура, модуль или объект.

В моделях разработки SDLC, STLC, V Model модульное тестирование - это первый уровень тестирования, выполняемый перед интеграционным тестированием. Модульное тестирование - это метод тестирования WhiteBox, который обычно выполняется разработчиком. На деле же из-за нехватки времени или халатности разработчиков, иногда модульное тестирование приходится проводить QA инженерам.

Зачем нужно модульное тестирование?

Отсутствие модульного тестирования при написании кода значительно увеличивает уровень дефектов при дальнейшем (интеграционном, системном, и приемочном) тестировании. Качественное модульное тестирование на этапе разработки экономит время, а следовательно, в конечном итоге, и деньги.

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

Понимание концепции модульного тестирования

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

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

Модульное тестирование включает в себя фреймворки модульного тестирования, драйверы, заглушки и имитирующие / поддельные объекты. Он работает на основе метода белого ящика, в котором проверяются условия, циклы и покрытие кода.

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

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

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

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

При ручном модульном тестировании, как правило используется пошаговая инструкция.

Алгоритм же автоматизированного заключается в следующем:

Разработчик записывает в приложение единицу кода, чтобы протестировать ее. После: они комментируют и, наконец, удаляют тестовый код при развертывании приложения.
Разработчик может изолировать единицу кода для более качественного тестирования. Эта практика подразумевает копирование кода в собственную среду тестирования. Изоляция кода помогает выявить ненужные зависимости между тестируемым кодом и другими модулями или пространствами данных в продукте.
Кодер обычно использует UnitTest Framework для разработки автоматизированных тестовых случаев. Используя инфраструктуру автоматизации, разработчик задает критерии теста для проверки корректного выполнения кода, и в процессе выполнения тестовых случаев регистрирует неудачные. Многие фреймворки автоматически отмечают и сообщают, о неудачных тестах и могут остановить последующее тестирование, опираясь на серьезность сбоя.
Алгоритм модульного тестирования:Создание тестовых случаев
Просмотр / переработка
Базовая линия
Выполнение тестовых случаев.

Как автоматизация тестирования использует модульное тестирование

Поскольку все больше и больше организаций переходят на гибкую модель, тестирование (как ручное, так и автоматическое) начинается на начальном этапе SDLC. Ускорение процесса автоматизации играет ключевую роль. Теперь мы знаем, что в гибких требованиях постоянно меняются, разработка все еще продолжается, и в этой ситуации API и макеты могут быть очень полезны для автоматизации.

Использование имитирующих объектов. Мокинг данных может использоваться для ускорения процесса, а не в зависимости от реальных тестовых данных. Когда тест автоматизации взаимодействует со свойствами объекта, а не с его функциями и поведением, можно использовать насмешку. Мокинг в основном требуется, когда приложение взаимодействует с какой-либо внешней службой, но его можно использовать и в других сценариях.

Мок-объект можно использовать, когда реальный объект:

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

Для Mocking доступны различные библиотеки. Вот некоторые фреймворки для имитации: Mockito, powermock и easymock для имитации.

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

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

Инструменты модульного тестирования

Есть несколько автоматизированных инструментов, доступных для помощи в модульном тестировании. Ниже мы приведем несколько примеров:

Junit : Junit — это бесплатный инструмент тестирования, используемый для языка программирования Java. Предоставляет утверждения для определения метода испытаний. Этот инструмент сначала проверяет данные, а затем вставляет их в кусок кода.
NUnit : NUnit — широко используемая среда модульного тестирования для всех языков .net. Это инструмент с открытым исходным кодом, который позволяет писать сценарии вручную. Он поддерживает управляемые данными тесты, которые могут выполняться параллельно.
JMockit : JMockit — это инструмент модульного тестирования с открытым исходным кодом. Это инструмент покрытия кода с метриками линий и путей. Позволяет имитировать API с синтаксисом записи и проверки. Этот инструмент предлагает покрытие линии, покрытие пути и покрытие данных.
EMMA : EMMA — это набор инструментов с открытым исходным кодом для анализа и составления отчетов о коде, написанном на языке Java. Эмма поддерживает типы покрытия, такие как метод, линия, базовый блок. Он основан на Java, поэтому не имеет внешних библиотечных зависимостей и может обращаться к исходному коду.
PHPUnit : PHPUnit — это инструмент модульного тестирования для программиста PHP. Он берет небольшие порции кода, называемые модулями, и тестирует каждый из них в отдельности. Этот инструмент также позволяет разработчикам использовать заранее определенные методы утверждений, чтобы утверждать, что система ведет себя определенным образом.

Заключение.

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

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