Вы сторонник TDD практики, но считаете, ее затратной или у вас не хватает времени на ее поддержание? Хочу предложить вам альтернативу — FTDD (Feature Test Drive Development) — в своем докладе я расскажу о реализации FTDD подхода для разработки встроенного ПО, который заменил классический TDD с юнит тестами, но сохранил качество.
TDD (Test Driven Development) практика является одной из первых, которая рекомендуется в Agile, так как она способствует повышению качества кода и тестового покрытия. Однако, несмотря на всю детально описанную пользу от ее использования, многие команды ей пренебрегают, так как она требует значительных ресурсов, как для начальной разработки, так и для последующего поддержания и этой же практикой жертвуют первой, когда поджимают сроки.
Особенно сложно использовать TDD при разработке встроенного ПО, ввиду сложности отладки. FTDD — подход, который поддерживает туже парадигму, что и TDD, но является более легковесным и требует меньше усилий на разработку и поддержку чем Unit Testing. Я расскажу, как в одном из центров разработки был разработан собственное фреймворк для реализации FTDD для встроенного ПО, и как код покрывался фича-тестами. И о том, как FTDD гармонично вписался в Continious Integration практику.
Сначала аудиторию раскрутили на пятиминутку ненависти к TDD (кстати, аудитория не очень повелась).
Сложно привыкнуть ментально
Требуется больше времени на разработку и поддержку
Рефакторинг приводит к переписыванию тестов
Не применим к тестированию UI
Не тестирует временные зависимости
Сомневаются в необходимости
Жертвуют первой! (Когда нужно захватить рынок — не до юнит-тестов)
Сложно использовать для встроенного ПО (компилятор, ОС)
По сути, среди сбокуперечисленных причин, для докладчика ключевой была последняя.
Конкретно, они при разработке встроенного ПО не пользовались симуляторами, и Mock-ированием особенностей железа, т.е. цикл был простой
компиляция → прошивка образа в железо → тестирование
Сложно судить, насколько это оптимально, ну, по крайней мере в космос для отладки не запускали.
Конечно, если вендор железа адекватный симулятор не дал, то писать его своими силами наверно без шансов.
(Мне показалось, что там речь идет даже о Windows Embedded, но попытка перетащить и юнит-тестировать код под обычными виндами оказалась не адекватна).
Разумеется, тащить и прошивать юнит-тесты на реальное железо не хотелось, и поэтому докладчик изобрел тесты.
Просто автоматические тесты (хотя докладчик ввел трейдмарк Feature Test Driven Development), местами интеграционные, местами функциональные, местами наверно и регрессионные.
Тесты, которые можно писать на питоне тестировщиками, которые отвязаны от железа, более гибкие и общаются с ним сигналами по Serial Interface.
Набросали небольшой Test Engine вокруг этого: XML-описания команд для девайса, Python-скрипты проверки, автоматический прогон этих тесткейсов с получением лога.
Цифры там какие-то такие: 70 KCLOC на плюсах, и сотня таких тестов.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
