TDD для микроконтроллеров, Как использовать модульное тестирование для железа Опции

[Serega Doc]

Доброго всем дня.
Наткнулся на статьи Развитие в направлении разработки встроенных систем и Эффективная разработка встроенного ПО через тестирование про модульное тестирование для встроенных систем.
Хочу уточнить есть unit тесты и mock объекты для компиляторов под AVR/STM8?
Что бы свою программу на с++ можно было покрывать тестами. Вести разработку ПО максимально отделив логику от уровня железа.
И при этом не испытывать проблем или же минимизировать вопросы перехода с одной платформы на другую.
Как например есть программа для контроллера AVR и по каким либо причинам (дефицит, цена, характеристики) решили перейти на STM8.
Переписываем классы взаимодействия с аппаратурой контроллера и в минимальные сроки получаем работоспособную (не проваливающую тесты) программу.

[Serega Doc]

о направлении проектирования (сверху вниз, в обратную сторону или промежуточный вариант)

- поясните пожалуйста. Не понял что имеется в виду.

Тестирование в не целевом окружении возможно лишь для задач не зависящих от железа как

Если например парсер какого-нить протокола, то без разницы где его тестить (если писать без хаков, конечно)

Если же существует контроллер с обвеской: регистры, ключи, кнопки, LCD экраны и прочее. И тестирование нужно проводить с учетом нюансов электронной схемы.
Подскажите насколько правильна вот такая структура формирования тестов:

И тогда можно получать информацию о прохождении тестов либо в симуляторе (например Протеус) либо в реальной плате + терминал COM порта.

[Непомнящий Евген...]

Тестирование в не целевом окружении возможно лишь для задач не зависящих от железа как
Если же существует контроллер с обвеской: регистры, ключи, кнопки, LCD экраны и прочее. И тестирование нужно проводить с учетом нюансов электронной схемы.

Есть разные виды тестирования. Для модульных тестов целевое окружение не нужно, потому что тестится конкретная подсистема. Все остальные подсиситемы, с которыми она взаимодействует, заменяются заглушками. Например для парсера пакетов модбас совершенно безразличны нюансы электронной схемы...

И еще вопрос - какие именно аспекты вы сможете потестить в железе? Например, сможете ли вы сэмулировать различные ошибки на TWI или UART, проблемы инициализации дисплея и т.д.

Все равно ничто не отменит тестирования всего изделия целиком, в том виде, как оно будет поставляться клиенту. А та штука, которую нарисовали вы, достаточно геморройна в реализации...

Исходя из этого, лично я остановился на:
1. модульных тестах, идущих на компе - запускаются из командной строки, отрабатывают очень быстро
2. автоматическом тестировании в железе готовой прошивки - занимает уже неск часов
3. ручном тестировании в железе готовой прошивки - занимает неск дней, делается отдельными людьми

[MrYuran]

3. ручном тестировании в железе готовой прошивки - занимает неск дней, делается отдельными людьми

происходит в течение всего жизненного цикла изделия