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

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

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

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

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

Здравствуйте, советую вот эту книгу.

По моему одна из лучших книг по тестированию встроенного ПО:
Testing embedded software - Bart Broekman and Edwin Notenboom
Наити ее в свободном доступе не очень просто, если кто не найдет, пишите в личку - вышлю мылом.


Я бы к вам не пошел работать. На проекте, где я сейчас работаю, диаметрально противоположная организация рабочего процесса. Идёт постоянный обмен опытом и ротация зон ответственности, чтоб ни один сотрудник не становился незаменимым носителем уникальных знаний. Даже если половина сотрудников отдела пойдёт в отпуск или заболеет, оставшиеся смогут выполнить их работу, пусть и медленнее.
А с такой организацией труда как вы описываете, я имел "счастье" сталкиваться на прошлой работе. Больше не хочется.
Этот подход работает в небольших локализованных компаниях, а в более-менее крупных и тем более распределённых, не работает даже на простых проектах.
С наступающим Вас!

Вообще, ИМХО, нет какого то единого стандартного подхода к тестированию, как к hardware, так и к software. Этот вопрос был всегда актуален и подлежит изучению. Для 'софтавщиков' есть даже отдельная профессия – тестеры ПО. Есть множество книжек с различными классификациями способов и методов тестирования, которые так и не удается упорядочить (там их целый огород). Думаю тут все зависит от того, на сколько высока критичность к качеству ваших изделий (железок). К примеру, экспериментировать на живом объекте (например, в медицинском оборудовании) как то не гуманно. Придется писать unit test и др. тесты, описывающие все возможные варианты развития событий (хотя это практически не возможно). Моя деятельность связана с разработкой охранной техники, где критичность к стойкости, безотказности и скорости восстановления в случае «краха» менее значима, но все таки остается высокой. Я сначала тестирую все, что связано с аппаратными средствами (hardware), что касается софта, то мне проще это делать в Visual Studio, там для этого имеется специальный инструментарий. Не плохо бы иметь в устройстве внешнюю память, например spi FRAM, и писать туда по кольцу лог событий, стек вызовов и др. важные детали. Это позволит даже после зависания микроконтроллера восстановить картину событий и определить прямо или косвенно причину некорректной работы.


P.S.
Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию. (Второй закон Вейнберга)
Самая грубая ошибка будет выявлена, лишь когда программа пробудет в производстве, по крайней мере, полгода. (Постулаты Трумэна по программированию)

Смотрите в сторону юнит-тестирования, я для юнит-тестов на си использую cutest

Простейший юнит-тест с использовением cutest выглядит примерно так:



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

Так уж сложилось, что не привык писать юнит-тесты...
Зато считаю, что современные компиляторы имеют хорошие встроенные механизмы для статического (и синтаксического) тестирования.
Достаточно почитать доку на компилятор и можно найти целый арсенал замечательных ключей (пример для gcc):

Отдельно хочу рассказать о ключике:

Помимо прочего он позволяет отлавливать ошибки такого рода:

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

А я и не путаю. Я лишь делюсь своими знаниями.
И, по-моему, внятно излагаю свои мысли. Если есть сомнения, перечитайте название топика и вопросы ТС в первом сообщении...
Я предложил вариант как улучшить качество кода. В чём вы сомневаетесь?

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

Я сомневаюсь в том, что проверка корректности синтаксиса улучшает качество, можно совершенно корректно для компилятора написать вещи, которые содержат ошибки. Хотя чистота кода да - это полезное свойство. Вероятность, что пропущенный warning может привести к ошибке имеется. Но это никак не относится к тестированию.




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

ну а теперь объясните тупому, как Вы предлагаете писать код-тест (с точки зрения организации сего процесса).
Именно этот момент(читай реализация) перечёркивает(порой) все не плохие начинания и идеи

именно про это я и оговорился "..в том виде котором юзают юнит тесты.."

Если мы пишем юнит-тест для модуля Math, в котором есть АПИ функция sum, то пишем тест:


Прогоняем тест - он фейлится, потому что такая функция у нас пока что не написана. Пишем функцию, прогоняем тест до тех пор, пока успешно не прогонится.

Смотрите выше, andrewlekar на пальцах объяснил как это делается. Это классическое TDD. Написали тест, написали функцию. Для эмбедед, конечно, запуск юнит-тестов на таргете не всегда удобен, я бы даже сказал, что не требуется. Поэтому приходится грамотно разделять логику программы и обращение к железу. Этого достаточно, чтобы провести тестирование всей логики/математики на ПК. соответсвенно тесты не будут даже входить в прошивку, для которой обычно имеются жесткие ограничения на размер используемой памяти. Для некоторых вещей связанных с железом можно применить такие техники как Mock-объекты. Например, чтение с АЦП заменяем на чтение из файла. Вот вкратце, что можно сделать юнит-тестами. Можно, конечно, копнуть глубже, использовать всякие симуляторы, но зачастую допиливание нормальной модели занимает слишком много времени. Это оправдано только для проектов, которые необходимо развивать и поддерживать многие годы
Ну и не стоит забывать, что юнит-тесты это только одна из фаз тестирования системы.

Речь была про организацию сего процесса.
Поясню...
Под словом "МЫ" - Вы кого конкретно описываете?

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




Предлагаю не витать в облаках. А смотреть ышо выше

Повторю вопрос:

"как Вы предлагаете писать код-тест (с точки зрения организации сего процесса)."

Суть вопроса подчеркнул.
Для тех кто не понимает слова организовать - читать устроить. Т.е. речь идёт не о технических приёмах, а организационных.

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

Юнит тестирование применяется в больших иерархических проектах.

Очень сложно оценить по очертаниям развалин, из за какого именно кирпича в подвале рухнул дом. Лучше кирпичи тестировать отдельно

Если каждый кирпич тестировать на прочность, это автоматически приведет к уменьшению их ресурса. Соответсвенно и дом будет менее прочным.
И зачем искать виноватый кирпич если они все одинаковые?

Если они одинаковые, то и тестировать надо 1 кирпич (и не тот, который потом пойдет в фундамент дома). Так же надо тестировать и все остальное - не из одних же кирпичей дом строят

Ну тогда дом будет построен из обломков.

Угу. Видел я некоторые системы, так они были построены даже не из обломков, а скорее из щебенки
в принципе при наличии нормальной системы тестирования продукта в целом, unit тесты уже как бы и не обязательны - баги будут пойманы все равно, но если интересует не факт наличия багов, а работающая целая система, то unit тесты - как говорится must have (или отладка такой системы может превратится в кошмар)

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

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

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

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

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

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


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

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

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

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

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

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

Первая книжка про TDD, которую я прочитал и начал применять - именно "Test Driven Development for Embedded C".
Тут больше желание/возможности работника и работодателя, чем область применения.


А, вы не не про логику. Да, юнит тесты это про логику. Переполнения стека, утечки памяти - они не для этого.

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

Вообще-то да, не пишите тесты, не. Чем меньше рынок умеющих, тем дороже я это смогу продать .

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

Согласен, редко кому надо. В самсунге и люксофте интересовались, а местным не до этого.

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

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

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

Обычно на юнит-уровне тестирует сам программист, а QA тестируют функционально. Я как программист убиваю двух зайцев:
1. проверяю что оно работает "в общем"- мне быстрее и проще это делать на юнит уровне чем функционально.
2. проверяю такие кейсы, которые QA-цы функционально никогда не протестируют.

Это что-то новое, код вроде не "изнашивается" от количества его выполнений

Здесь не выполнения кода обсуждается, а его перенос в различные окружения и среды.