Тренинг «Unit Testing & TDD»

24 ак. часа, 18 астр. часов

Цели тренинга

После тренинга участники смогут:

• Объяснить себе и менеджменту, где им нужны тесты, а где нет
• Разрабатывать тесты как «спецификации на примерах» в роли документации
• Разрабатывать поддерживаемые тесты и их наборы по модели
• Подменять сложные компоненты системы на время тестирования
• Анализировать тестовое покрытие для принятия решений по тест-дизайну
• Обеспечивать поддерживаемый дизайн системы при помощи TDD

В итоге бизнес получает:

• Контролируемый cycle time задач
• Контролируемое качество системы

Программа

Зачем мы собрались? (1 часа всего / из них 0.5 часа практики)

• Обзор тренинга
• О тренере
• Разбивка по парам и знакомство-представление друг друга
• Приоритезация целей тренинга и сбор проблем

Fork and then clone codebase for further development

git clone --depth 1 -b <YYYY-MM-project> http://github.com/eugene-krivosheyev/unit-testing-and-tdd

Что такое автотест? (1.5/0.5)

• Каковы цели и задачи авто тестов?
• В чем отличие от отладки?
• Определение модуля и возможные виды модулей

Live Coding Demo на примере "общеизвестного класса"

• Подключение основного фреймворка
• Понятие контракта по Б. Мейеру
• Именование тест-кейса/тест-класса и теста/тест-метода
• Понятие трасс выполнения (flows) и граничные условия
• Подходы AAA и GWT из BDD
• Роль фикстуры
• Забытый полуторный этап
• Тест = фиксированная трасса выполнения
• Тестовый набор = спецификация компонента

Coding Iteration #01

• Given legacy codebase with Client and SavingAccount domain types
• When developers add guard clauses for creating Client and SavingAccount
• And cover these components with maintainable autotests
• Then coverage for these components should be ≥ 80%
• And public code review should state for maintainability

Как замерять тестовое покрытие? (0.5/0)

• Понятие покрытия
• Виды расчета покрытия
• Инструменты расчета покрытия
• Анализ текущего покрытия
• Что покрывать в первую очередь в проектах?

Как ускорить разработку автотестов за счет готовых фреймворков и библиотек? (1/0.5)

• Подключение вспомогательных фреймворков: build tool
• Условное выполнение тестов
• Типизированные сравнения средствами основного фреймворка средствами основного фреймворка
• Типизированные сравнения средствами отдельного фреймворка
• Типизированные сравнения средствами отдельного фреймворка
• Исключения
• Таймауты
• Параметризованные тесты
• Расширения, в том числе готовые

Coding Iteration #02

• Given legacy codebase with Client and SavingAccount domain types
• When developers add consistency rules for linking Client and SavingAccount
• And cover these components with maintainable autotests
• Then coverage for these components should be ≥ 90%
• And public code review should state for maintainability

Как писать интеграционные и модульные тесты? (1/0.5)

• В чем их специфика? Системные vs Интеграционные vs Модульные
• Как по коду определить скоуп?
• Виды тест-дублеров: dummy, stub, fake, mock, spy
• State-based testing VS Interaction-based testing
• Фреймворк тест-дублеров уровня объектов и интеграция с основным тестовым фреймворком
• Фреймворк тест-дублеров уровня REST-сервисов
• Фреймворк тест-дублеров уровня REST-сервисов
• Как среда сборки различает UT и IT

Coding Iteration #03

• Given legacy codebase with Processing component
• When developers analyse and refactor production codebase for testability
• And cover this component with maintainable unit autotests
• Then coverage for these component should be ≥ 90%
• And public code review should state for maintainability

Реализация фикстуры для обеспечения поддерживаемости тестов (1.5/1)

• Когда и сколько раз создается объект тестового класса?
• Как максимально реюзать фикстуры?
• Наследование тест-кейсов
• Методы жизненного цикла теста
• Fixture Builders

Coding Iteration #04

• Given test codebase
• When developers analyse and refactor test codebase for maintainability
• Then public code review should state for tests maintainability

---

Как группировать тесты в наборы? (0.5/0)

• Зачем нужны test suites?
• Вложенные тесты
• Теги и запуск набора
• Способ фильтрации средствами среды сборки модульных и интеграционных тестов

Как поддерживать качество тестов и снижать дублирование? (1/0.5)

Как обеспечить качество самих тестов?

• Сначала поломанный тест
• Анализ тестового покрытия
• Ревью кода тестов
• Mutation coverage

Анти-паттерны разработки модульных тестов: "вредные советы"

• Отношение к тестам не как к обычному коду
• Большие расфокусированные тесты
• Неговорящие имена
• Дублирование фикстуры
• Стопроцентное покрытие

Coding Iteration #05

• Given test codebase
• When developers analyse and refactor test codebase for maintainability
• Then cross-team code review should state for tests maintainability

Как обеспечить тестопригодность дизайна legacy системы? (1.5/0.5)

• Как оценить тестопригодность legacy code?
• Метрика Coupling
• Метрика Cohesion
• Понятность/осознаваемость
• Каков тестопригодный дизайн?

Live Coding Demo для реализации компонента Reporting и нового CheckingAccount

• Принципы проектирования SOLID
• Шаблоны Factory и DI
• Шаблоны Strategy/State
• Ключевая диллема покрытия legacy code?

Coding Iteration #06

• Given legacy codebase with Reporting component
• When developers implement polymorphic testable implementation for Reporting and CheckingAccount
• Then cross-team code review should state for its testability

---

Какую ценность дает практика TDD? (0.5/0)

• Что такое TDD?
• TDD как практика проектирования
• Зачем нужен TDD?
• Минимизация отладки
• Снижение затрат на инкрементальную разработку
• Быстрая обратная связь
• Повышение поддерживаемости дизайна
• Удобство API "из коробки"
• Тесты как документация
• Предсказуемость поставки
• Чистый работающий код
• Управление страхом

В каком ритме писать по TDD? (1.5/0.5)

• Red – Green – Refactor
• Скорость отработки тестового набора как предусловие практики TDD

Live Coding Demo для компонента Branch

• Операция добавления в branch

Coding Iteration #07

• Given legacy codebase with Branch domain type
• When developers implement full-functional Branch implementation
• And made it through TDD cycles
• Then coverage for this component should be 100%
• And public code review should state for maintainability

Базовые шаблоны TDD (1.5/1)

• Test First
• Isolated Tests
• Assertion First
• Test Data
• Child Test
• Test List
• Mock Object
• Crash Test Dummy

Coding Iteration #08

• Given legacy codebase with Reporting service
• When developers implement reporting operation for branch
• And made it through TDD cycles
• Then coverage for this component should be 100%
• And coverage for this component should state this is unit tests
• And public code review should state for maintainability

Шаблоны красной и зеленой полосы (1.5/1)

Красной полосы

• One-step Test
• Starter Test
• Another Test
• Regression Test

Зеленой полосы

• Obvious Implementation
• Triangulation
• One to Many

Coding Iteration #09: TDD Ping-pong

• Given legacy codebase with Reporting service
• When developers implement reporting operations
• And made it through TDD cycles in pair ping-pong rules
• Then coverage for this component should be 100%
• And coverage for this component should state this is unit tests
• And public code review should state for maintainability

Как внедрить UT&TDD в процесс разработки? (0.5/0)

Каковы затраты на UT&TDD?

• Постановка экономической задачи

Типовые ошибки TDD

• Code First
• Too Many Obvious Implementation
• Too Many Triangulations
• Coverage Affinity
• Implementation Testing but not Contract Testing

Как внедрить?

• Общение с менеджментом
• Secure sandbox
• Последовательное расширение scope

Финальная ретроспектива (1/0.5)

• План конкретных ближайших действий

Буфер (2)

• Auto-testing and DB: patterns
• Test data generation: mockaroo, generatedata, 10 and 15 tools, Faker, PG, not only db