Обсуждение:Тестирование встроенного ПО: альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011)/Заметки Стаса Фомина
Сначала аудиторию раскрутили на пятиминутку ненависти к TDD (кстати, аудитория не очень повелась).
- Сложно привыкнуть ментально
- Требуется больше времени на разработку и поддержку
- Рефакторинг приводит к переписыванию тестов
- Не применим к тестированию UI
- Не тестирует временные зависимости
- Сомневаются в необходимости
- Жертвуют первой! (Когда нужно захватить рынок — не до юнит-тестов)
- Сложно использовать для встроенного ПО (компилятор, ОС)
По сути, среди сбокуперечисленных причин, для докладчика ключевой была последняя. Конкретно, они при разработке встроенного ПО не пользовались симуляторами, и Mock-ированием особенностей железа, т.е. цикл был простой
компиляция → прошивка образа в железо → тестирование
Сложно судить, насколько это оптимально, ну, по крайней мере в космос для отладки не запускали. Конечно, если вендор железа адекватный симулятор не дал, то писать его своими силами наверно без шансов. (Мне показалось, что там речь идет даже о Windows Embedded, но попытка перетащить и юнит-тестировать код под обычными виндами оказалась не адекватна).
Разумеется, тащить и прошивать юнит-тесты на реальное железо не хотелось, и поэтому докладчик изобрел тесты. Просто автоматические тесты (хотя докладчик ввел трейдмарк Feature Test Driven Development), местами интеграционные, местами функциональные, местами наверно и регрессионные. Тесты, которые можно писать на питоне тестировщиками, которые отвязаны от железа, более гибкие и общаются с ним сигналами по Serial Interface. Набросали небольшой Test Engine вокруг этого: XML-описания команд для девайса, Python-скрипты проверки, автоматический прогон этих тесткейсов с получением лога. Цифры там какие-то такие: 70 KCLOC на плюсах, и сотня таких тестов.
Ну и как бы «PROFIT!»©.
«Когда нужно захватить рынок — не до юнит-тестов.».
Один интеграционный тест дешевле.