Персональные инструменты
 

Тестирование встроенного ПО: альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011)

Материал из CustisWiki

Перейти к: навигация, поиск

Аннотация

Докладчик
Дмитрий Овечкин

Вы сторонник TDD практики, но считаете, ее затратной или у вас не хватает времени на ее поддержание? Хочу предложить вам альтернативу — FTDD (Feature Test Drive Development) — в своем докладе я расскажу о реализации FTDD подхода для разработки встроенного ПО, который заменил классический TDD с юнит тестами, но сохранил качество.

TDD (Test Driven Development) практика является одной из первых, которая рекомендуется в Agile, так как она способствует повышению качества кода и тестового покрытия. Однако, несмотря на всю детально описанную пользу от ее использования, многие команды ей пренебрегают, так как она требует значительных ресурсов, как для начальной разработки, так и для последующего поддержания и этой же практикой жертвуют первой, когда поджимают сроки.

Особенно сложно использовать TDD при разработке встроенного ПО, ввиду сложности отладки. FTDD — подход, который поддерживает туже парадигму, что и TDD, но является более легковесным и требует меньше усилий на разработку и поддержку чем Unit Testing. Я расскажу, как в одном из центров разработки был разработан собственное фреймворк для реализации FTDD для встроенного ПО, и как код покрывался фича-тестами. И о том, как FTDD гармонично вписался в Continious Integration практику.

Видео

Конференция «Application Developer Days-2011» приглашает участников и докладчиков!

Конференция Application Developer Days-2011 приглашает участников и докладчиков!

Для этого доклада нужен подкаст (аудиозапись)?

  •  Да, многое понятно и без видео части, есть смысл его прослушать.
  •  Нет, аудиозапись бесполезна (не понять без видео или вообще мало смысла в докладе).

Презентация

Тестирование встроенного ПО — альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011).pdf Тестирование встроенного ПО — альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011).pdf Тестирование встроенного ПО — альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011).pdf Тестирование встроенного ПО — альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011).pdf Тестирование встроенного ПО — альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011).pdf Тестирование встроенного ПО — альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011).pdf Тестирование встроенного ПО — альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011).pdf Тестирование встроенного ПО — альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011).pdf Тестирование встроенного ПО — альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011).pdf Тестирование встроенного ПО — альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011).pdf Тестирование встроенного ПО — альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011).pdf Тестирование встроенного ПО — альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011).pdf Тестирование встроенного ПО — альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011).pdf Тестирование встроенного ПО — альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011).pdf

Примечания и отзывы

Сначала аудиторию раскрутили на пятиминутку ненависти к TDD (кстати, аудитория не очень повелась).

  • Сложно привыкнуть ментально
  • Требуется больше времени на разработку и поддержку
  • Рефакторинг приводит к переписыванию тестов
  • Не применим к тестированию UI
  • Не тестирует временные зависимости
  • Сомневаются в необходимости
  • Жертвуют первой! (Когда нужно захватить рынок — не до юнит-тестов)
  • Сложно использовать для встроенного ПО (компилятор, ОС)

По сути, среди сбокуперечисленных причин, для докладчика ключевой была последняя. Конкретно, они при разработке встроенного ПО не пользовались симуляторами, и Mock-ированием особенностей железа, т.е. цикл был простой компиляция → прошивка образа в железо → тестирование Сложно судить, насколько это оптимально, ну, по крайней мере в космос для отладки не запускали. Конечно, если вендор железа адекватный симулятор не дал, то писать его своими силами наверно без шансов. (Мне показалось, что там речь идет даже о Windows Embedded, но попытка перетащить и юнит-тестировать код под обычными виндами оказалась не адекватна).

Разумеется, тащить и прошивать юнит-тесты на реальное железо не хотелось, и поэтому докладчик изобрел тесты. Просто автоматические тесты (хотя докладчик ввел трейдмарк Feature Test Driven Development), местами интеграционные, местами функциональные, местами наверно и регрессионные. Тесты, которые можно писать на питоне тестировщиками, которые отвязаны от железа, более гибкие и общаются с ним сигналами по Serial Interface. Набросали небольшой Test Engine вокруг этого: XML-описания команд для девайса, Python-скрипты проверки, автоматический прогон этих тесткейсов с получением лога. Цифры там какие-то такие: 70 KCLOC на плюсах, и сотня таких тестов.

Ну и как бы «PROFIT!»©.



«Когда нужно захватить рынок — не до юнит-тестов.».

Один интеграционный тест дешевле.

Докладчик
Дмитрий Овечкин
Компания
Innova Systems

Почти не запомнил доклад.

Без комментариев.



Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.