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

531 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
531
On SlideShare
0
From Embeds
0
Number of Embeds
92
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • State диаграмма
  • demo
  • on liners
  • Добавить инструмент
  • Посмотреть ксюшину презентацию
  • Добавить машинку с захардкоженным двигателем
    ----- Meeting Notes (19/03/2014 20:58) -----
    инициализация классов внутри класса
  • С каждым if’oм больше тестов
  • Пример мокаПример Синглтона
    Разжижение кодовой базы
  • Code coverage
  • Иконку сонара
  • Тестирование весна 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

    ×