1. Модульное тестирование
Влад Алюков

2. О чём
 (Зачем нужны модульные unit) тесты
 Что они из себя представляют
 Подходы к написанию тестов
 Анализ существующих тестов
 Антипаттерны в проектировании тестов
 Как написать нетестопригодный код
 Статический анализ кода
2

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

4. UNIT test
4

5. Зачем писать unit-тесты?
 Уменьшение количества итераций
> >Разработка Тестирование Разработка
 Качество кода
 Более лёгкое внесение изменений
 Документация
5

6. :Зачем Качество кода
6

7. :Зачем Простое внесение
изменений
7

8. :Зачем Документация
8

9. Пирамида тестирования
9

10. Превосходство модульных
тестов
 Скорость
 Надёжность
 Стабильность
10

11. Скорость
11

12. Надёжность
12

13. Стабильность
13

14. Анатомия теста
14
 Инициализация контекста ( )опционально
 Выполнение проверок
 Очистка контекста ( )опционально
 Отчётность

15. Задачи фрэймворка
 Структура для написания тестов
 Запуск тестов
 Отчёты
15

16. Пример использования
фрэймворка
16

17. Репорты
 Html Report
 xUnit Report
 Text Report
17

18. Тестовые фрейморки xUnit
18
unit test framework #{lang}

19. Пример тестов на
фибоначчи
 Разбор тестируемого метода
 Определение граничных значений
 Определение классов эквивалентности
19

20. ( )Виды проверок ассертов
20

21. 21
Антипаттерны в
тестировании

22. False Positive
 assertTrue(True)
 Пустое тело метода
22

23. Зависимый
 Зависит от окружения
 Операционная система
 Расположение файлов
 Зависит от других тестов
 Один тест подготавливает данные для другого
23

24. Inspector
 Использует знание о структуре объектов
(reflection api)
 Изменение атрибутов доступа тестируемого класса
 Получение приватных значение тестируемого класса
24

25. GodTest
 Задействует много посторонних объектов
и подсистем
 В случае падения трудно определить причину
 По большому счёту является уже больше
интеграционным тестом, нежели unit
25

26. Неинформативные имена
26

27. Медленные тесты
27
 Unit-test не должны выполнятся больше
секунды
 Что замедляет
 Ввод/вывод
 Обработка сложных структур данных
 sleep

28. Заглушки
 Эмуляция hardware интерфейсов
 Внешние зависимости
Виды
 Stub ― заглушка для объекта
 Mock ― эмул яция объекта
 Dummy – Пустой объект
28

29. Mock/Stub (Demo)
29

30. Альтернативный подход
(DocTest)
30
Классический тест:

31. Альтернативный подход
(DocTest)
31

32. DocTest
 Преимущества
 Актуальные примеры использования
 Простота написания
 Недостатки
 Развесистая документация
 Нецелевое использование docstring
 Неудобно работать с фикстурами
32

33. 33
Практики написания
тестов

34. TDD
34

35. TDD
Плюсы
 Отслеживание прогресса
 Документирование
 Архитектура “в нагрузку”
 Перенос процесса отладки на начальную стадию
Минусы
 Высокий порог вхождения
35

36. Пример TDD (ruby)
36

37. 37
Анализ существующих
тестов

38. Анализ покрытия
38

39. Метрики
 По файлам
 По классам
 По состояниями
 По линиям кода
39

40. Обманчивое покрытие
 !Примеры когда покрытие лжет
40

41. Инструменты
 Emma(java)
 Simplecover (ruby)
 Sonar
41

42. Mutation Testing
42

43. Возможные мутации
( )мутанты
43

44. Эквивалентные мутанты
44

45. 45
Антипаттерны в
разработке

46. Сильно связанный код
 (Монолитная кодовая база инициализация
)классов внутри класса
 Сложность в разделении на модули
 Перегруженные тесты
46

47. “Тяжёлые” конструкторы
 Конструкторы содержащие создание или
настройку членов класса
 ,Не поддаются изоляции от членов класса
для тестирования необходимо подгружать
.другие модули
47

48. “Тяжёлые” методы
 Очень большое тело метода
 Много аргументов на вход
 Передача контекстного объекта в тело
метода
Проблемы в тестировании
 Более сложные тесты
Вероятно метод реализует слишком много
,логики необходимо разделение на
.объекты
48

49. Цикломатическая сложность
 Количество путей выполнения программы
 –Выше цикломатическая сложность
сложнее тестировать
 Каждый дополнительный операнд у if
увеличивает количество необходимых
2тестов минимум на
49

50. God Object
 « »Класс всё включено
 ,Обычно содержит в себе тяжёлые методы
и тяжёлый конструктор
 Слишком много логики сосредоточено в
,объекте сложность в тестовой
, .декомпозиции сложность дизайна тестов
50

51. Singleton
 Паттерн позволяющий создавать
единственный экземпляр объекта
 Отравляемый контекст
Минусы:
 Применение данного паттерна может
привести к неприятным side- .эффектам
 (Конкуренции за доступ в highload
)проектах
51

52. Dependency Injection
 Паттерн проектирования понижающий
связанность кода
Фреймворки:
 Guice (java)
 Spring (java)
52

53. Статический анализ кодовой
базы
 Связанность кода
 Опасные конструкции
 Опечатки
 Копипаст
 Утечки памяти
 Code Convention
 Цикломатическая сложность
53

54. Sonar
54

55. Sonar
55

56. Домашнее задание
 Сделать форк проекта server с моего
гитхаба
 Обеспечить его тестовое покрытие не
85ниже %
 Замеряем покрытие cobertura
 Метрика branch coverage
 Задание выполняется индивидуально
56

57. 57
?Вопросы

58. Спасибо за внимание
Влад Алюков
v.alyukov@corp.mail.ru