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

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

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

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

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

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

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

• 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

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

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

• 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

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

• 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

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

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

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

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

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

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

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

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

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

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

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

• 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

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

• 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

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

• Obvious Implementation
• Triangulation
• One to Many

• 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

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

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

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

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

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