Test Driven Development          TDD, UTDD + Embedded SW DevelopmentAlexey Litvin                                     SaM ...
Что Внутри?A.   Концепция TDDB.   Тестировать перед написанием кода: это возможно?C.   А надо ли, или что мне это даст?D. ...
TDD ConceptКлассический TDD   Его недостатки                                    Недостатки:                               ...
Разработка системыОбычный   Идеальный   Пример в вакууме: «Системапроцесс    процесс    оповещения о температуре          ...
Пример архитектуры системы            Требования:              Режим работы от 0 до +30              градусов             ...
BANG! Пример-то неудачный! Ошибка в        Модульархитектуре   нетестируемый   Где выгода:                                ...
Пример архитектуры системы №2             Требования:               Режим работы от 0 до +30               градусов       ...
Test First!                               Набор тестов:                                    Query: GetTemp()               ...
Чудо-модуль   Набор тестов:             Где выгода:   •   Query: GetTemp()      Result: query done       Ошибка дизайна н...
Гарантия выполнения функций                           Где выгода:                              Ошибка дизайна найдена ДО  ...
Вариант TDDКлассический TDD          Преимущества:                            Тесты, созданные на первом                  ...
Подробнее о Unit тестах
ИТОГО (достоинства)Прямые последствия:                     Неявные последствия:•   Раннее обнаружение ошибок дизайна   •  ...
ИТОГО (недостатки)Да, они есть:•   В общем больше кода•   Не страхует от интеграционных ошибок и ошибок в требованиях•   Т...
Как?   Попробовать!   Тестирование своего кода – признак уважения к коллегам.   Test First – это (просто) – думать о тр...
Спасибо за внимание!     www.sam-solutions.com     SaM Solutions Minsk       15 Filimonova St,     220037 Minsk, Belarus  ...
Upcoming SlideShare
Loading in …5
×

Pragmatic Test Driven Development. Теория.

764 views

Published on

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
764
On SlideShare
0
From Embeds
0
Number of Embeds
224
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Pragmatic Test Driven Development. Теория.

  1. 1. Test Driven Development TDD, UTDD + Embedded SW DevelopmentAlexey Litvin SaM SolutionsProject Coordinator Value of Talent. Delivered.Certified ScrumMaster www.sam-solutions.comE-mail: a.litvin@sam-solutions.comICQ: 309-169-225 Minsk 2013Skype: a.litvin
  2. 2. Что Внутри?A. Концепция TDDB. Тестировать перед написанием кода: это возможно?C. А надо ли, или что мне это даст?D. Вроде бы неплохо. Как это применить?
  3. 3. TDD ConceptКлассический TDD Его недостатки Недостатки: Refactoring можно забыть Тест, созданный на первом этапе покрывает только «позитивный» сценарий Модификация тестов может проводиться без модификации дизайна – возможны интеграционные ошибки
  4. 4. Разработка системыОбычный Идеальный Пример в вакууме: «Системапроцесс процесс оповещения о температуре воздуха» Требования: Режим работы от 0 до +30 градусов При температуре выше X – SMS с указанием температуры При температуре ниже Y – SMS c указанием температуры При сбое системы – SMS с “ALARM!!!”
  5. 5. Пример архитектуры системы Требования: Режим работы от 0 до +30 градусов При температуре выше X – SMS с указанием температуры При температуре ниже Y – SMS c указанием температуры При сбое системы – SMS с “ALARM!!!”
  6. 6. BANG! Пример-то неудачный! Ошибка в Модульархитектуре нетестируемый Где выгода: Ошибка дизайна найдена ДО имплементации
  7. 7. Пример архитектуры системы №2 Требования: Режим работы от 0 до +30 градусов При температуре выше X – SMS с указанием температуры При температуре ниже Y – SMS c указанием температуры При сбое системы – SMS с “ALARM!!!”
  8. 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. 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. 10. Гарантия выполнения функций Где выгода: Ошибка дизайна найдена ДО имплементации У модуля определены интерфейсы, хотя самого модуля еще нет Разработчик точно знает, что должен делать модуль - if…else >> case…esac Модуль не упадет в случае - var a >> var b получения некорректных - etc… данных Модуль работает корректно независимо от внутренней реализации
  11. 11. Вариант TDDКлассический TDD Преимущества: Тесты, созданные на первом этапе покрывают все сценарии Модификация тестов проводится только при изменении требований к модулю Все изменения внутренней реализации почти никогда не требуют изменения тестов
  12. 12. Подробнее о Unit тестах
  13. 13. ИТОГО (достоинства)Прямые последствия: Неявные последствия:• Раннее обнаружение ошибок дизайна • Снижает вероятность• Способствует созданию модульной «переписывания» системы архитектуры • Возникшие ошибки быстро• Гарантирует неизменное соотносятся с модулем функционирование модуля • Упрощает поддержку системы, т.к. независимо от реализации Failed тест не позволит новому• Помогает разработчику функционалу «поломать» имеющийся концентрироваться на требованиях • Без «лишнего» кода финальная• Хорошее покрытие тестами повышает система менее ресурсоемка качество конечного программного • Трудозатраты на отладку снижаются – кода вам почти не нужен отладчик• Программная составляющая хорошо • Упрощается задача поиска ошибок в покрыта тестами аппаратной части
  14. 14. ИТОГО (недостатки)Да, они есть:• В общем больше кода• Не страхует от интеграционных ошибок и ошибок в требованиях• Требуются дополнительные инструменты (xUnit, etc.)• Для повышения эффективности требуется code review• Необходимо поддерживать тестовый код. Для максимальной эффективности – интеграция с CI системой• Code visibility, необходимый для тестов, может повлечь нарушения политики сокрытия данных и методов (e.g. private methods in OOP)• Не обойтись без «переделки восприятия»
  15. 15. Как? Попробовать! Тестирование своего кода – признак уважения к коллегам. Test First – это (просто) – думать о требованиях. Ломать архитектуру в начале проекта – это хорошо! …и слушатьследующего докладчика!
  16. 16. Спасибо за внимание! www.sam-solutions.com SaM Solutions Minsk 15 Filimonova St, 220037 Minsk, Belarus Tel.: +375 17 3091709 Fax: +375 17 3091717

×