Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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. Теория.

875 views

Published on

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

  • Be the first to comment

  • Be the first to like this

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

×