Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

550 views

Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

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

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

×