Embed Size (px)
Citation preview
Модульное тестирование
Влад Алюков
О чём
Зачем нужны модульные(unit) тесты Что они из себя представляют Подходы к написанию тестов Анализ существующих тестов Антипаттерны в проектировании тестов Как написать нетестопригодный код Статический анализ кода
2
3
Модульное тестирование
UNIT test
4
Зачем писать unit-тесты?
Уменьшение количества итераций Разработка > Тестирование > Разработка
Качество кода Более лёгкое внесение изменений Документация
5
Зачем: Качество кода
6
Зачем: Простое внесение изменений
7
Зачем: Документация
8
Пирамида тестирования
9
Превосходство модульных тестов
Скорость Надёжность Стабильность
10
Скорость
11
Надёжность
12
Стабильность
13
Анатомия теста
14
Инициализация контекста (опционально)
Выполнение проверок Очистка контекста (опционально) Отчётность
Задачи фрэймворка
Структура для написания тестов Запуск тестов Отчёты
15
Пример использования фрэймворка
16
Репорты
Html Report xUnit Report Text Report
17
Тестовые фрейморки xUnit
18
unit test framework #{lang}unit test framework #{lang}
Пример тестов на фибоначчи
Разбор тестируемого метода Определение граничных значений Определение классов эквивалентности
19
Виды проверок (ассертов)
20
21
Антипаттерны в тестировании
False Positive
assertTrue(True) Пустое тело метода
22
Зависимый
Зависит от окружения Операционная система Расположение файлов
Зависит от других тестов Один тест подготавливает данные для другого
23
Inspector
Использует знание о структуре объектов (reflection api) Изменение атрибутов доступа тестируемого
класса Получение приватных значение тестируемого
класса
24
GodTest
Задействует много посторонних объектов и подсистем В случае падения трудно определить причину По большому счёту является уже больше
интеграционным тестом, нежели unit
25
Неинформативные имена
26
Медленные тесты
27
Unit-test не должны выполнятся больше секунды
Что замедляет Ввод/вывод Обработка сложных структур данных sleep
Заглушки
Эмуляция hardware интерфейсов Внешние зависимости
Виды Stub ― заглушка для объекта Mock ― эмул яция объекта Dummy – Пустой объект
28
Mock/Stub (Demo)
29
Альтернативный подход (DocTest)
30
Классический тест:
Альтернативный подход (DocTest)
31
DocTest
Преимущества Актуальные примеры использования Простота написания
Недостатки Развесистая документация Нецелевое использование docstring Неудобно работать с фикстурами
32
33
Практики написания тестов
TDD
34
TDD
Плюсы Отслеживание прогресса Документирование Архитектура “в нагрузку” Перенос процесса отладки на начальную
стадию
Минусы Высокий порог вхождения
35
Пример TDD (ruby)
36
37
Анализ существующих
тестов
Анализ покрытия
38
Метрики
По файлам По классам По состояниями По линиям кода
39
Обманчивое покрытие
Примеры когда покрытие лжет!
40
Инструменты
Emma(java) Simplecover (ruby) Sonar
41
Mutation Testing
42
Возможные мутации (мутанты)
43
Эквивалентные мутанты
44
45
Антипаттерны в разработке
Сильно связанный код
Монолитная кодовая база (инициализация классов внутри класса)
Сложность в разделении на модули Перегруженные тесты
46
“Тяжёлые” конструкторы
Конструкторы содержащие создание или настройку членов класса
Не поддаются изоляции от членов класса, для тестирования необходимо подгружать другие модули.
47
“Тяжёлые” методы
Очень большое тело метода Много аргументов на вход Передача контекстного объекта в тело
метода
Проблемы в тестировании Более сложные тесты
Вероятно метод реализует слишком много логики, необходимо разделение на объекты.
48
Цикломатическая сложность
Количество путей выполнения программы
Выше цикломатическая сложность – сложнее тестировать
Каждый дополнительный операнд у if увеличивает количество необходимых тестов минимум на 2
49
God Object
Класс «всё включено» Обычно содержит в себе тяжёлые
методы, и тяжёлый конструктор
Слишком много логики сосредоточено в объекте, сложность в тестовой декомпозиции, сложность дизайна тестов.
50
Singleton
Паттерн позволяющий создавать единственный экземпляр объекта
Отравляемый контекст
Минусы: Применение данного паттерна может
привести к неприятным side-эффектам. Конкуренции за доступ (в highload
проектах)
51
Dependency Injection
Паттерн проектирования понижающий связанность кода
Фреймворки: Guice (java) Spring (java)
52
Статический анализ кодовой базы
Связанность кода Опасные конструкции Опечатки Копипаст Утечки памяти Code Convention Цикломатическая сложность
53
Sonar
54
Sonar
55
Домашнее задание
Сделать форк проекта server с моего гитхаба
Обеспечить его тестовое покрытие не ниже 85%
Замеряем покрытие cobertura Метрика branch coverage Задание выполняется индивидуально
56
57
Вопросы?
