tdd (test-driven development) как стиль разработки
DESCRIPTION
Как превратить рутинное написание Unit тестов в увлекательный процесс? Как побороть страхи, что система не будет работать должным образом? Как уверенно решать самые сложные для себя задачи? Я расскажу как TDD поможет найти ответы на эти и другие вопросы.Наш сайт http://www.tuladev.netTRANSCRIPT
I. Происхождение TDDII. Основные принципы TDDIII. Мотивации использования TDDIV. TDD Best practicesV. Пример TDDVI. TDD – FAQ
Содержание
Методологии разработки ПО
Низкоформализованные Высокоформализованные
Каскадные
Итерационные
XProgramming
Как получится
Канбан
Scrum
ГОСТ
RUP
ISO
XProgramming. XP PracticesCustomer
Tests
PlanningGame
Small Releases
CollectiveOwnership
ContinuousIntegration
CodingStandart
WholeTeam
40h Week
PairProgramming
Refactoring
TDD
SimpleDesign
Metaphor
XProgramming. XP PracticesCustomer
Tests
PlanningGame
Small Releases
CollectiveOwnership
ContinuousIntegration
CodingStandart
WholeTeam
40h Week
PairProgramming
Refactoring
TDD
SimpleDesign
Metaphor
Основные принципы TDD
1. Пишем новый код, только тогда когда тест не сработал2. Удаляем дублирование
Всего 2 правила:
Цель TDD:
Мантра TDD
REFACTOR
RED
GREEN
Написать тесткоторый не проходит
Написать код,чтобы тест проходил
Убратьдублирование
Простые программные решения
Тесты придающие уверенность в работе
TDD – в пяти простых правилах
Добавляем тест
Запускаем все тесты
Добавляем небольшие изменения
Снова запускаем все тесты
Рефакторинг
Тесты не прошли
Тесты прошли
Тесты не прошли
Тесты прошлиТесты не прошли
Мотивации использования TDD
Темп разработки
Не писать лишнего кода
Проектировать less coupled системы
Возвращаться к коду
Начинать разрабатывать не теряя время
С первого раза (а значит быстрее) решать сложные задачи
Контролировать стресс. Постоянно видеть прогресс.
Исправлять ошибки на раннем этапе разработки
Мотивации использования TDD
TDD Best practices
Темп разработки
UnitTest – читаемый, простой, малосвязанный, быстрыйЛучше много простых тестов, чем один сложный.Начинаем писать тест с «Assert»Сначала пишем самые простые тестыСписок желаемых тестов на бумаге, не в коде и не в умеТесты должны работать быстроНе пишем код, пока на него нет тестаПишем наиболее простой код, необходимый чтобы тест прошелТолько что написанный тест должен падать (работает в 99%)После успешного прохождения теста - рефакторитьВсе тесты должны проходить перед написанием нового тестаРефакторинги и паттерны – друзья TDD
Пример TDDСоздание игры «Пятнашки»
TDD FAQ
Сколько писать тестов?
Можно ли начать использовать TDD прямо сейчас на
текущем проекте?
Можно ли использовать TDD для разработки
крупномасштабных систем?
Какие есть подходы cвязанные c TDD?
Негативные стороны TDD
…
Негативные стороны TDD
Темп разработки
Все проблемы UnitTest-ов
Не поддерживаются IntelliSense like tools
Тесты тоже требует рефакторингов.
Сложно применить TDD на плохой код
Тесты не гарантируют отсутствие ошибок
Резюме
Простые программные решения
Не пишем код, пока на него нет теста
Идем к цели маленькими шажками
Assert First
Refactor
Уверенность в работе
Список тестов на бумаге
Сначала простые тесты
Покрытие тестами
Less coupled modules
Средства Результат