Как тестировать код для встраиваемых систем Опции

[Муравей]

Здравствуйте.
Уже достаточно давно пишу код для всяких контроллеров, но задачи были малой и средней сложности. Хватало функционального тестирования, написал программку, протестировал на весь описанный в ТЗ функционал, прошёлся по всему пользовательскому интерфейсу и Ок. Т.е. программные модули по серьёзному, раздельно, не тестировал, только прошивку целиком прямо на конечной платформе.
Как-то взяло сомнение, что это правильный подход , особенно если сложность задач возрастёт и если в проекте будет больше одного программиста :)
Посмотрел на книгу Мартин Р. - Чистый код. Создание, анализ и рефакторинг (Библиотека программиста) - 2010. Целая теория правильного программирования. Но применима ли эта теория для embedded кода?
В общем посоветуйте плз. какую-то литературку на эту тему, может быть какие-то жизненные советы как повысить качество кода, как гарантировать , что программный модуль будет нормально стыковаться с другими модулями и в случае необходимости портироваться на другие системы, и т.д......
Заранее спасибо.

[AlexandrY]

Посмотрел на книгу Мартин Р. - Чистый код. Создание, анализ и рефакторинг (Библиотека программиста) - 2010. Целая теория правильного программирования. Но применима ли эта теория для embedded кода?

Да книжонка забавная. Но акценты для embedded не совсем актуальны, ИМХО.

Важнее становятся аппаратные ошибки и даже не из-за невнимательности, а из-за не полной документированности аппаратной среды в которой
работает программа.
Скажем что делать когда модуль DMA выдал ошибку доступа к шине, и при этом не известно ни кто ни что там пересылал по DMA, и что пропало и что передалось.
И как правильно построить архитектуру чтобы справляться с такими ошибками и не затормозить систему до нуля, и не дать другим процессам уйти в состояние underflow?

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

Да, а насчет тестирования ничего сказать не могу. Не оправдывается какое-то другое тестирование кроме как на живом объекте.
Лучше сконцентрировать усилия на способах надежного накопления и передачи отладочной информации с объектов и обновления firmware.