Test Driven Development TDD, UTDD + Embedded SW Development

SaM Solutions

Value of Talent. Delivered.

www.sam-solutions.com

Minsk 2013

Alexey Litvin

Project Coordinator

Certified ScrumMaster

E-mail: a.litvin@sam-solutions.com

ICQ: 309-169-225

Skype: a.litvin

Что Внутри?

A. Концепция TDD

B. Тестировать перед написанием кода: это возможно?

C. А надо ли, или что мне это даст?

D. Вроде бы неплохо. Как это применить?

TDD Concept

Недостатки:

Refactoring можно забыть

Тест, созданный на первом этапе

покрывает только «позитивный»

сценарий

Модификация тестов может

проводиться без модификации

дизайна – возможны

интеграционные ошибки

Классический TDD Его недостатки

Разработка системы

Пример в вакууме: «Система

оповещения о температуре

воздуха»

Требования:

Режим работы от 0 до +30

градусов

При температуре выше X –

SMS с указанием температуры

При температуре ниже Y – SMS

c указанием температуры

При сбое системы – SMS с

“ALARM!!!”

Обычный процесс

Идеальный процесс

Пример архитектуры системы

Требования:

Режим работы от 0 до +30

градусов

При температуре выше X – SMS с

указанием температуры

При температуре ниже Y – SMS c

указанием температуры

При сбое системы – SMS с

“ALARM!!!”

BANG! Пример-то неудачный!

Где выгода:

Ошибка дизайна

найдена ДО

имплементации

Ошибка в архитектуре

Модуль нетестируемый

Пример архитектуры системы №2

Требования:

Режим работы от 0 до +30

градусов

При температуре выше X – SMS с

указанием температуры

При температуре ниже Y – SMS c

указанием температуры

При сбое системы – SMS с

“ALARM!!!”

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”

Важно! Тестируем только тот модуль,

который разрабатываем!

Чудо-модуль

Где выгода:

Ошибка дизайна найдена ДО

имплементации

У модуля определены

интерфейсы, хотя самого

модуля еще нет

Разработчик точно знает, что

должен делать модуль

Модуль не упадет в случае

получения некорректных

данных

Набор тестов: • 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”

Гарантия выполнения функций

Где выгода:

Ошибка дизайна найдена ДО

имплементации

У модуля определены

интерфейсы, хотя самого

модуля еще нет

Разработчик точно знает, что

должен делать модуль

Модуль не упадет в случае

получения некорректных

данных

Модуль работает корректно

независимо от внутренней

реализации

- if…else >> case…esac - var a >> var b - etc…

Вариант TDD

Преимущества:

Тесты, созданные на первом

этапе покрывают все сценарии

Модификация тестов

проводится только при

изменении требований к

модулю

Все изменения внутренней

реализации почти никогда не

требуют изменения тестов

Классический TDD

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

ИТОГО (достоинства)

Неявные последствия:

• Снижает вероятность «переписывания» системы

• Возникшие ошибки быстро соотносятся с модулем

• Упрощает поддержку системы, т.к. Failed тест не позволит новому функционалу «поломать» имеющийся

• Без «лишнего» кода финальная система менее ресурсоемка

• Трудозатраты на отладку снижаются – вам почти не нужен отладчик

• Упрощается задача поиска ошибок в аппаратной части

Прямые последствия:

• Раннее обнаружение ошибок дизайна

• Способствует созданию модульной архитектуры

• Гарантирует неизменное функционирование модуля независимо от реализации

• Помогает разработчику концентрироваться на требованиях

• Хорошее покрытие тестами повышает качество конечного программного кода

• Программная составляющая хорошо покрыта тестами

ИТОГО (недостатки)

Да, они есть:

• В общем больше кода

• Не страхует от интеграционных ошибок и ошибок в требованиях

• Требуются дополнительные инструменты (xUnit, etc.)

• Для повышения эффективности требуется code review

• Необходимо поддерживать тестовый код. Для максимальной эффективности – интеграция с CI системой

• Code visibility, необходимый для тестов, может повлечь нарушения политики сокрытия данных и методов (e.g. private methods in OOP)

• Не обойтись без «переделки восприятия»

Как?

Попробовать!

Тестирование своего кода – признак уважения к коллегам.

Test First – это (просто) – думать о требованиях.

Ломать архитектуру в начале проекта – это хорошо!

…и слушать следующего докладчика!

www.sam-solutions.com

Спасибо за внимание!

SaM Solutions Minsk

15 Filimonova St,

220037 Minsk, Belarus

Tel.: +375 17 3091709 Fax: +375 17 3091717