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