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

[Муравей]

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

[andrewlekar]

Это типа программист который реализует код или кто?

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

Вы конкретно писали юнит тесты? К коду который так-же сами и написали? Или как?

Да, писал. К коду, который сам же и написал.

Суть юнит-тестов не в какой-то бюрократии или 100% покрытии, а в подготовке кода к рефакторингу. Юнит-тестирование позволяет уменьшить вероятность, что что-то сломается при рефакторинге, а также предполагает переработку архитектуры кода в плане тестируемости. Эта переработка архитектуры подготавливает код к дальнейшему изменению, т.е. при добавлении новой фичи меньше вероятность, что придётся всё раскурочивать.

[kolobok0]

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

Замечательно..
Ну а теперь посмотрите о чём велась речь выше:

Цитата(kolobok0): "в том виде котором юзают юнит тесты они проверяют только изменение кода со временем. И больше ничего."

Цитата(vanner): "первая задача модульного тестирования - это проверка корректности работы функции (модуля), т.е.
проверка условия что при указаных входных данных получается корректный результат и/или корректная обработка ошибки.
Проверка регрессий это уже побочный эффект по-сути, при наличии ранее работоспособных тестов легко определить какое
изменение сломало модуль. "
(извините за полное цитирование)

Так, что уважаемый andrewlekar - наши с вами восприятия нахрена это нужно - имеют один вектор.
А вот господин vanner ожидает(насколько я его смог понять) = "проверка корректности работы функции" .

Я заострил внимание именно на организационном моменте. Т.к. именно он определяет качество самих тестов в
плане "корректности работы функции".
Объясняю:
Лично мне слабо понимается сам процесс написания кода программистом, и написание тестов к нему этим-же программистом.
Тесты в этом случае могут НЕ ВЫЯВИТЬ "некорректности работы функции". Т.е. вряд ли правая рука сможе
написать такого, что упустит в реализации левая. А левая вряд ли будет тестировать то, что НЕ написала(либо не знала) правая
рука одного и того-же человека.

Надеюсь мысль передал.
Остаётся только всё то вспомогательное которое не имеет отношения к качеству и уменьшению затрат при производстве
(читай при запуске в производство) программного кода. Т.е. если Вы допустили ошибку, то она честно и провериться с ошибкой
и уйдёт с ошибкой дальше....

ЗЫ
Забегая вперёд, отвечу - я не против механики. Я считаю, что метода хромает. Метода, которая увы и ах применяется повсеместно (противного
не наблюдал). Т.е. написал человек код, написал к нему тест... А как деление на ноль было так и осталось. Вряд-ли человек напишет проверку
выше по уровню знаний чем его же написанный код, который он тестирует.

[Idle]

качество самих тестов.

Это один из моментов зачем нужен TDD. Тест может содержать ошибку. Для проверки что сам тест правильный, он выполняется два раза - до написания кода (тест должен вернуть ошибку), и после.

[kolobok0]

...проверки что сам тест правильный, ...до написания кода (тест должен вернуть ошибку)...

Ваш пример показывает, что тест охватывает сам интерфейс, а не реализацию.
пример:

берём класс строка, который может содержать в себе и ноль так-же (ну например: стандартный CString от MFC).
Не всякий программист, обрабатывая строки это может осязать. Как следствие - режутся данные до нулевого символа.

Это как один из множества, и... "лёгкий" пример.
Поверьте мне дураку - таких нюансов очень и очень много.