Доклад в двух частях (практика и теория) от специалистов компании SaM Solutions, применявших TDD на практике. Практика: http://www.slideshare.net/samsolutionsby/pragmatic-tdd-practice

1. Test Driven Development
TDD, UTDD + Embedded SW Development
Alexey Litvin
SaM Solutions
Project Coordinator Value of Talent. Delivered.
Certified ScrumMaster
www.sam-solutions.com
E-mail: a.litvin@sam-solutions.com
ICQ: 309-169-225 Minsk 2013
Skype: a.litvin

2. Что Внутри?
A. Концепция TDD
B. Тестировать перед написанием кода: это возможно?
C. А надо ли, или что мне это даст?
D. Вроде бы неплохо. Как это применить?

3. TDD Concept
Классический TDD Его недостатки
Недостатки:
Refactoring можно забыть
Тест, созданный на первом этапе
покрывает только «позитивный»
сценарий
Модификация тестов может
проводиться без модификации
дизайна – возможны
интеграционные ошибки

4. Разработка системы
Обычный Идеальный Пример в вакууме: «Система
процесс процесс оповещения о температуре
воздуха»
Требования:
Режим работы от 0 до +30
градусов
При температуре выше X –
SMS с указанием температуры
При температуре ниже Y – SMS
c указанием температуры
При сбое системы – SMS с
“ALARM!!!”

5. Пример архитектуры системы
Требования:
Режим работы от 0 до +30
градусов
При температуре выше X – SMS с
указанием температуры
При температуре ниже Y – SMS c
указанием температуры
При сбое системы – SMS с
“ALARM!!!”

6. BANG! Пример-то неудачный!
Ошибка в Модуль
архитектуре нетестируемый Где выгода:
Ошибка дизайна
найдена ДО
имплементации

7. Пример архитектуры системы №2
Требования:
Режим работы от 0 до +30
градусов
При температуре выше X – SMS с
указанием температуры
При температуре ниже Y – SMS c
указанием температуры
При сбое системы – SMS с
“ALARM!!!”

8. Test First!
Набор тестов:
Query: GetTemp()
 Result: query done
Input: X+1,0
 Result: “=X+1,0”
Query: GetTemp()
 Result: query done
Input: Y-1,0
 Result: char “=Y-1,0”
Query: GetTemp()
 Result: query done
Input: X
 Result: none
Query: GetTemp()
 Result: query done
Input: -300,0
 Result: “ALARM”
Важно! Query: GetTemp()
 Result: query done
Тестируем только тот модуль, Input: “zxc”
который разрабатываем!  Result: “ALARM”

9. Чудо-модуль
Набор тестов: Где выгода:
• Query: GetTemp()
 Result: query done Ошибка дизайна найдена ДО
Input: X+1,0 имплементации
 Result: “=X+1,0”
У модуля определены
• Query: GetTemp() интерфейсы, хотя самого
 Result: query done модуля еще нет
Input: Y-1,0 Разработчик точно знает, что
 Result: char “=Y-1,0” должен делать модуль
• Query: GetTemp() Модуль не упадет в случае
 Result: query done получения некорректных
Input: X данных
 Result: none
• Query: GetTemp()
 Result: query done
Input: -300,0
 Result: “ALARM”
• Query: GetTemp()
 Result: query done
Input: “zxc”
 Result: “ALARM”

10. Гарантия выполнения функций
Где выгода:
Ошибка дизайна найдена ДО
имплементации
У модуля определены
интерфейсы, хотя самого
модуля еще нет
Разработчик точно знает, что
должен делать модуль
- if…else >> case…esac Модуль не упадет в случае
- var a >> var b получения некорректных
- etc… данных
Модуль работает корректно
независимо от внутренней
реализации

11. Вариант TDD
Классический TDD Преимущества:
Тесты, созданные на первом
этапе покрывают все сценарии
Модификация тестов
проводится только при
изменении требований к
модулю
Все изменения внутренней
реализации почти никогда не
требуют изменения тестов

12. Подробнее о Unit тестах

13. ИТОГО (достоинства)
Прямые последствия: Неявные последствия:
• Раннее обнаружение ошибок дизайна • Снижает вероятность
• Способствует созданию модульной «переписывания» системы
архитектуры • Возникшие ошибки быстро
• Гарантирует неизменное соотносятся с модулем
функционирование модуля • Упрощает поддержку системы, т.к.
независимо от реализации Failed тест не позволит новому
• Помогает разработчику функционалу «поломать» имеющийся
концентрироваться на требованиях • Без «лишнего» кода финальная
• Хорошее покрытие тестами повышает система менее ресурсоемка
качество конечного программного • Трудозатраты на отладку снижаются –
кода вам почти не нужен отладчик
• Программная составляющая хорошо • Упрощается задача поиска ошибок в
покрыта тестами аппаратной части

14. ИТОГО (недостатки)
Да, они есть:
• В общем больше кода
• Не страхует от интеграционных ошибок и ошибок в требованиях
• Требуются дополнительные инструменты (xUnit, etc.)
• Для повышения эффективности требуется code review
• Необходимо поддерживать тестовый код. Для максимальной эффективности –
интеграция с CI системой
• Code visibility, необходимый для тестов, может повлечь нарушения политики
сокрытия данных и методов (e.g. private methods in OOP)
• Не обойтись без «переделки восприятия»

15. Как?
 Попробовать!
 Тестирование своего кода – признак уважения к коллегам.
 Test First – это (просто) – думать о требованиях.
 Ломать архитектуру в начале проекта – это хорошо!
…и слушать
следующего докладчика!

16. Спасибо за внимание!
www.sam-solutions.com
SaM Solutions Minsk
15 Filimonova St,
220037 Minsk, Belarus
Tel.: +375 17 3091709
Fax: +375 17 3091717