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

[Serega Doc]

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

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

Ну так а что мешает?

Слой, независимый от железа, можно гонять на настольном компе и покрывать любыми тестами. Я использую библиотечку googletest, есть и дофига других.

Рядом с googletest болтается и библиотечка для mock-объектов, я ее правда не использовал.

[MrYuran]

Тесты обязательно должны проводиться непосредственно в целевом железе.
Иначе смысла особого нет.

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

Эта тема немного перекликается с другой - о направлении проектирования (сверху вниз, в обратную сторону или промежуточный вариант).
Ну и ещё - со стандартизацией кодирования.

Осталось подумать, как реализовать.
Я лично вижу так:
1. Уровень сопряжения с железом тестируется с помощью осциллографа и других измерительных приборов.
2. На него сверху цепляется некая прослойка-монитор, которая может читать и писать в память, запускать функции и тд.
3. Через канал связи (например, UART) эта технологическая прослойка цепляется к GDB.

Далее, на ПК запускаем серию тестов и смотрим результаты.
Осталось всё красиво увязать.

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

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

Тесты обязательно должны проводиться непосредственно в целевом железе.
Иначе смысла особого нет.

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

[Serega Doc]

Ну так а что мешает?

Слой, независимый от железа, можно гонять на настольном компе и покрывать любыми тестами. Я использую библиотечку googletest, есть и дофига других.

Рядом с googletest болтается и библиотечка для mock-объектов, я ее правда не использовал.

А вы под какую платформу используете googletest? И как вы интегрировали эти тесты с компилятором для железа?
Что бы запускать их непосредственно из среды в которой пишем программу.

Если можно то по подробнее пожалуйста.

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

А вы под какую платформу используете googletest?

С и С++ - кроссплатформенные языки. Части программы, написанные без использования платформо-зависимых вещей можно запускать где угодно. В своем коде я выделил такие части и тестирую их на персоналке. Тесты гоняю под MinGW и Visual C++, сейчас думаю прикрутить еще один компилер.

И как вы интегрировали эти тесты с компилятором для железа?

Никак. Большинство либ для тестов используют стандарную библиотеку с++ и под МК не скомпиляются. В принципе можно написать собственную библиотечку тестирования под МК, но смысла я особого не вижу. На компе тесты выполняются практически мгновенно, их удобно отлаживать и т.д.

Что бы запускать их непосредственно из среды в которой пишем программу.

Я работаю в eclipse, для МК компиляю IAR-ом, вызывая его из scons-файла. Также в scons завернуты тесты, только там вызываются настольные компилеры. Результат падает в консоль.

Это что касалось unit-тестов.

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

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

[_Pasha]

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

Встречное направление, ибо эти две сущности - первый шаг после ТЗ и уровень примитивов - остаются неизменными.
А вот насчет гонять данные через канал связи - частенько потолок бит-рейта мешает и тогда это плавно переходит в гемор. Приходится лезть в протеус

[Serega Doc]

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

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

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

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

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

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

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

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

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

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

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

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

[MrYuran]

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

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

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

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

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

[MrYuran]

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

7. Заключение

UniTesK удобен для функционального тестирования встроенного ПО:

* формальные спецификации UniTesK удобны для формализации требований к встроенному программному обеспечению;
* тестовые сценарии позволяют компактно записывать сложные тестовые последовательности;
* механизм медиаторов предоставляет гибкие средства для отделения сценариев и формальной модели от реализации, позволяют строить различные схемы развёртывания тестового стенда

Вот ещё

и ещё

[_Pasha]

Какая-то телепатия... Не далее, как позавчера, завис на очередных довесках к прототредам. Все, что читаю сейчас- так или иначе охвачено в моих потугах. TinyOS, ессо, и близко нету

[MrYuran]

Какая-то телепатия... Не далее, как позавчера, завис на очередных довесках к прототредам. Все, что читаю сейчас- так или иначе охвачено в моих потугах.

А я, кстати, с вашей подачи полез искать, после темы про SED и AWK - вот видимо, причина синхронизма

TinyOS, ессо, и близко нету

А я давно приглядываюсь, очень интересный подход.
В том числе и применительно к тестированию. И даже заточено под мои любимые MSP430