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

Ссылки сюда (2) →

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

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

По сути, среди сбокуперечисленных причин, для докладчика ключевой была последняя. Конкретно, они при разработке встроенного ПО не пользовались симуляторами, и Mock-ированием особенностей железа, т.е. цикл был простой

компиляция → прошивка образа в железо → тестирование

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

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

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

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

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