Тестирование встроенного ПО: альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011)
Содержание
Аннотация
- Докладчик
- Дмитрий Овечкин
Вы сторонник 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 на плюсах, и сотня таких тестов.
Ну и как бы «PROFIT!»©.
«Когда нужно захватить рынок — не до юнит-тестов.».
Один интеграционный тест дешевле.
- Докладчик
- Дмитрий Овечкин
- Компания
- Innova Systems
Почти не запомнил доклад.
Без комментариев.
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».