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

[Муравей]

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

[andrewlekar]

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

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

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

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

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

[kolobok0]

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

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

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

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

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

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

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

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

[vanner]

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

Надеюсь мысль передал.

Да, абсолютно понятна ваша мысль, вы совершенно не занимаетесь проектированием своего ПО. Конечно трудно протестировать спаггети-код который делает несколько функций сразу, да еще программист пишет одной рукой В общем, читайте книги, практикуйтесь, со временем все придет

[AlexandrY]

Да, абсолютно понятна ваша мысль, вы совершенно не занимаетесь проектированием своего ПО. Конечно трудно протестировать спаггети-код который делает несколько функций сразу, да еще программист пишет одной рукой В общем, читайте книги, практикуйтесь, со временем все придет

А пример реальной функции которую вы подвергали юнит-тестированию можете дать?

Я расшифровываю понятие юнит-тестирование как тестирование элементарных функций (unit - единица, элемент)
Зачем нужно тестировать элементраные функции охватываемы взглядом, вроде таких: с = a + b, если вы в своем уме и доверяете глазам ?

Причина такой паранойи, на мой взгляд, может скрываться в объектных языках и объектных моделях.
Это свойственно C++ с переопределением операций, шаблонами и прочими фичами, и больше актульно программистам на PC которые пишут код не комприлируемый напрямую в ассемблер или базирующийся на объектных библиотеках представляющих собой черный ящик.
У них действительно простое сложение может дать непредсказуемый результат только из-за того, что где-то далеко в хидерах изменилось какое-то объявление или сменилась версия библиотек.

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