Тестирование весна 2014 смешанное занятие 2

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

Влад Алюков

О чём

Зачем нужны модульные(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

Вопросы?

Спасибо за внимание

Влад Алюков v.alyukov@corp.mail.ru