Модульное тестирование

Модульное тестирование

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

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

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

Рефакторинг кода
Рефакторинг кода – процесс улучшения кода без внесения изменений функциональности.
Грязный код:
появляется в процессе частых изменений;
низкая квалификация, лень;
источник ошибок и непредсказуемого поведения
Чистый код:
легкость чтения, понимания и поддержки;
снижение вероятности появления ошибок;
упрощение отлова и исправления ошибок;

Области тестирования
Тестирование нецелесообразно:
1.1 – простой код без зависимостей – код тривиальный и не предполагает ошибок
1.2 – сложный код с большим количеством зависимостей – код плохо скомплектован и требует пересмотра
Тестирование целесообразно:
2.1 – сложный код без зависимостей – обычно правильно описанная бизнес-логика
2.2 – простой код с зависимостями – обычно код, связывающий различные компоненты, соприкасается с интреграционном тестированием
Количество
зависимостей
Сложность компонента

ПРИНЦИПЫ
F.I.R.S.T.
CLEAN CODE
BY ROBERT MARTIN

FAST
Проблема медленных тестов:
Запускаются редко
->
Повышается вероятность пропуска ошибки
->
«Дырявые» тесты требуют постоянной переработки
->
Поддержка тестов откладывается
->
Повышается вероятность выхода ошибок в production.
Быстрота = скорость выполнения + легкость понимания
Пути повышения быстроты тестов:
Один assert за тест;
Использование Dependency Injection;
Интуитивно-понятное именование;
Применение DSL (domain-specific language);

INDEPENDENT
ISOLATED
Независимость тестов достигается путем применения паттерна BUILD – OPERATE – CHECK.
BUILD – настройка теста
OPERATE – запуск тестируемой функциональности
CHECK – сравнение полученного результата с ожидаемым

REPEATABLE
Повторяемость достигается с помощью применения тестовых двойников (test doubles):
Dummy objects – передаваемые, но неиспользуемые объекты;
Fake objects – заведомо подмененные системы с аналогичной функциональностью, но упрощенные для использования в тестовом случае (InMemoryDatabases, HashTables, etc.);
Mocks – заглушки, предназначенные для регистрации вызовов;
Stubs – заглушки, отвечающие на вызовы согласно настроенному сценарию ответов;
Spies – заглушки (аналогично Stubs), но позволяющие регистрировать действия;
* by Martin Fowler

SELF-VALIDATING
Результат теста должен представлять собой булево значение и не требовать дополнительной интерпретации.
Принцип достигается, используя:
Булев результат;
Один assert на тест;
Build – Operate – Check паттерн;
True
False

Значение новых модульных тестов падает пропорционально объему написанного кода.
Высшее выражение принципа – TDD подход.
TIMELY

Эволюция модульного тестирования

Фреймворк JUnit
JUnit – фреймворк автоматизированного модульного тестирования для Java. Также портирован на многие языки программирования.
Основные особенности JUnit-тестов:
регрессионность;
повторяемость
Разработчики: Кент Бек, Эрих Гамма
Платформа: Java
Преимущества:
доступен для написания модульных и интеграционных тестов;
является хорошим средством документирования кода;
совместимость с популярными IDE;
использует синтаксис Java;
Недостатки:
Не осуществляет тестирование зависимостей;

История JUnit

JUnit 4
Annotations

JUnit 4
Assertions

ЗАМЕТКИ НА ПОЛЯХ
JUnit 4

Фреймворк Junit 5
JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage
JUnit Platform – платформа для запуска TestEngine API.
JUnit Jupiter – проект для написания и запуска тестов, написания собственных расширений.
JUnit Vintage – проект для обеспечения совместимости с предыдущими версиями JUnit.
Основные нововведения JUnit 5:

JUnit 5
Annotations

JUnit 5
Extensions
Одно из нововведений JUnit 5 – расширения (extensions), заменяющие правила (rules) JUnit 4.
JUnit 5 определяет 5 типов расширений:
test instance post-processing – расширение применяется после создания сущности теста;
conditional test execution – определяет, будет ли запускаться тест
life-cycle callbacks – связан с вызовом методов обратного вызова;
parameter resolution – позволяет работать с параметризованными методами;
exception handling – позволяет определять логику в случае выбрасывания исключения.

Библиотеки модульного тестирования
AssertJ – библиотека с открытым исходным кодом, предназначенная для написания наглядных и интуитивно понятных assert’ов. Активно применяется для тестирования совместно с JUnit.
Точка входа в выражения AssertJ – assertThat(), в которым передаются тестируемые данные. Само выражение не выполняет проверку, а позволяет строить проверочные цепочки.
import static org.assertj.core.api.Assertions.*;
Hamcrest – библиотека, работающая совместно с JUnit в качестве имплементации механизма проверок.
Точка входа в выражения Hamcrest – assertThat(), в которую передаются тестируемые данные.
Выражение в общем случае получает в виде параметров исследуемый объект, условия проверки и текст сообщения.
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.*;