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

[Муравей]

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

[andrewlekar]

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

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

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

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

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

[kolobok0]

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

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

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

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

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

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

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

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

[Idle]

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

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

[kolobok0]

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

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

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

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

[Idle]

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

Вы про то, что программист может забыть написать обработку такого варианта? Да, если забыл один кейс, то сто других тестов на сто других кейсов тут не помогут.

тест охватывает сам интерфейс, а не реализацию.

Не, ну как - на каждый нюанс поведения функции свой тест.

[AlexandrY]

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

Это все похоже не про встраиваемые системы.

А вот сегодня пришло из рассылки barrgroup: http://www.edn.com/design/automotive/44234...ts-consequences
Очень поучительная история про ошибку в систему управления TOYOTA которая привела к фатальным последствиям.

Эксперты по программному обеспечению NASA оказались бессильны (видать юнит-тесты пытались применить)
А в реальности это наименее важный момент.
Самое опасное это Single points of failure (SPOF), обнаружить которые не поможет ни один юнит-тест. Еще очень опасен программно-аппаратный симбиоз багов.
Вторая показательная ошибка - тестирование в отрыве от платформы. Переполнение стека RTOS ну очень сложно заметить моделируя софт на PC (чем наверно и занималось NASA) .

Есть там и интересные рекомендации по организации тестирования.

Интересна отсылка к оценке параметра под названием Cyclomatic complexity, как предсказателю количества ошибок.
Странно но в популярных IDE такой фичи не встречал.

[XVR]

Эксперты по программному обеспечению NASA оказались бессильны (видать юнит-тесты пытались применить)

юнит-тесты никоим образом не должны заменять тестирование системы в целом. Юнит тесты - это первая линия тестирования (и в принципе она вообще может отсутствовать), но никак не последняя Они предназначены для быстрой ловли ошибок в самых базовых объектах программы, которые могут проявиться потом в любом месте и в любом виде. Эти тесты не дают никакой гарантии работоспособности системы, на них не оценивают никаких метрик полноты тестирования (например покрытия кода), и вообще их фэйлы может увидеть только непосредственно девелопер у себя на столе (с такими файлами система дальше этого самого стола ни имеет права никуда уйти).

Интересна отсылка к оценке параметра под названием Cyclomatic complexity, как предсказателю количества ошибок.
Странно но в популярных IDE такой фичи не встречал.

Видел в VS 2012 (но только для .NET платформы)