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

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

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

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

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

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

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

Программа

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

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

Fork and then clone codebase for further development

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

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

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

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

1. Подключение основного фреймворка
2. Понятие контракта по Б. Мейеру
3. Именование тест-кейса и теста
4. Понятие трасс выполнения (flows) и граничные условия
5. Подход AAA
6. Подход GWT из BDD
7. Роль фикстуры
8. Забытый полуторный этап
9. Тест = фиксированная трасса выполнения
10. Тестовый набор = спецификация компонента

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 theses components should be ≥ 80%
• And public code review should state for maintainability

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

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

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

1. Подключение вспомогательных фреймворков
2. Простые сравнения средствами основного фреймворка
3. Типизированные сравнения средствами встроенного фреймворка
4. Типизированные сравнения средствами отдельного фреймворка
5. Таймауты
6. Исключения
7. Параметризованные тесты
8. Расширение поведения тестов с помощью запускальщиков и правил

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 theses components should be ≥ 90%
• And public code review should state for maintainability

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

1. В чем их специфика? Системные vs Интеграционные vs Модульные
2. Как по коду определить скоуп?
3. Виды тест-дублеров
4. State-based testing VS Interaction-based testing
5. Фреймворк тест-дублеров уровня объектов
6. Фреймворк тест-дублеров уровня REST-сервисов
7. Как среда сборки различает 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 theses component should be ≥ 90%
• And public code review should state for maintainability

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

1. Как максимально реюзать фикстуры?
2. Наследование тест-кейсов
3. Методы фреймворка
4. 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

---

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

1. Зачем нужны test suites?
2. Способы группировки "из коробки" фреймворка: группы и категории
3. Способ группировки средствами среды сборки

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

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

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

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

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

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

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

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

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

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

Coding Iteration #06

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

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

1. Что такое TDD?
2. TDD как практика проектирования
3. Зачем нужен TDD?
4. Минимизация отладки
5. Снижение затрат на инкрементальную разработку
6. Быстрая обратная связь
7. Повышение поддерживаемости дизайна
8. Удобство API "из коробки"
9. Тесты как документация
10. Предсказуемость поставки
11. Чистый работающий код
12. Управление страхом

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

1. Red – Green – Refactor
2. Скорость отработки тестового набора как предусловие практики 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

---

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

1. Test First
2. Isolated Tests
3. Assertion First
4. Test Data
5. Child Test
6. Test List
7. Mock Object
8. 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

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

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

1. One-step Test
2. Starter Test
3. Another Test
4. Regression Test

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

1. Obvious Implementation
2. Triangulation
3. 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

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

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

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

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

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

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

1. Code First
2. Too Many Obvious Implementation
3. Too Many Triangulations
4. Coverage Affinity
5. Implementation Testing but not Contract Testing

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

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

Буфер (2)