[Муравей 0]

Здравствуйте.

Уже достаточно давно пишу код для всяких контроллеров, но задачи были малой и средней сложности. Хватало функционального тестирования, написал программку, протестировал на весь описанный в ТЗ функционал, прошёлся по всему пользовательскому интерфейсу и Ок. Т.е. программные модули по серьёзному, раздельно, не тестировал, только прошивку целиком прямо на конечной платформе.

Как-то взяло сомнение, что это правильный подход , особенно если сложность задач возрастёт и если в проекте будет больше одного программиста :)

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

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

Заранее спасибо.

 

[AlexandrY 2]

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

 

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

 

Важнее становятся аппаратные ошибки и даже не из-за невнимательности, а из-за не полной документированности аппаратной среды в которой

работает программа.

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

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

 

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

Встраиваемый код не такой большой чтобы обращать внимание на его удобочитаемость. Инструменты рефакторинга из любого кода конфетку сделают за считанные часы.

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

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

Имена не то что должны быть удобочитаемые и понятные их просто должно быть меньше.

 

Да, а насчет тестирования ничего сказать не могу. Не оправдывается какое-то другое тестирование кроме как на живом объекте.

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

[Idle 0]

Здравствуйте.

...

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

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

 

[neiver 0]

По моему одна из лучших книг по тестированию встроенного ПО:

Testing embedded software - Bart Broekman and Edwin Notenboom

Наити ее в свободном доступе не очень просто, если кто не найдет, пишите в личку - вышлю мылом.

 

...

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

Встраиваемый код не такой большой чтобы обращать внимание на его удобочитаемость. Инструменты рефакторинга из любого кода конфетку сделают за считанные часы.

...

Я бы к вам не пошел работать. На проекте, где я сейчас работаю, диаметрально противоположная организация рабочего процесса. Идёт постоянный обмен опытом и ротация зон ответственности, чтоб ни один сотрудник не становился незаменимым носителем уникальных знаний. Даже если половина сотрудников отдела пойдёт в отпуск или заболеет, оставшиеся смогут выполнить их работу, пусть и медленнее.

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

Этот подход работает в небольших локализованных компаниях, а в более-менее крупных и тем более распределённых, не работает даже на простых проектах.

С наступающим Вас! :santa2:

[Danis 0]

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

 

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

 

 

P.S.

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

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

[cg_shura 0]

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

 

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

 

void testStrToInt(CuTest* tc) 
{
  int value;
  
  CuAssertTrue(tc, strToInt("123", &value));
  CuAssertIntEquals(tc, 123, value);

  CuAssertTrue(tc, !strToInt("abc", &value));
  CuAssertIntEquals(tc, 123, value);

  CuAssertTrue(tc, strToInt("  456  ", &value));
  CuAssertIntEquals(tc, 456, value);

  CuAssertTrue(tc, strToInt("-1024", &value));
  CuAssertIntEquals(tc, -1024, value);

  CuAssertTrue(tc, strToInt("+100000", &value));
  CuAssertIntEquals(tc, 100000, value);
}

 

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

Изменено 4 декабря, 2013 пользователем cg_shura

[demiurg_spb 0]

Так уж сложилось, что не привык писать юнит-тесты...

Зато считаю, что современные компиляторы имеют хорошие встроенные механизмы для статического (и синтаксического) тестирования.

Достаточно почитать доку на компилятор и можно найти целый арсенал замечательных ключей (пример для gcc):

    CFLAGS += -pedantic
    CFLAGS += -Wformat
    CFLAGS += -Wall
    CFLAGS += -Wextra
    CFLAGS += -Werror
    CFLAGS += -Wstrict-prototypes
    CFLAGS += -Wno-unused-local-typedefs
    CFLAGS += -Wno-unused-function
    CFLAGS += -Wno-missing-field-initializers
    CFLAGS += -Wno-main
    CFLAGS += -Wdouble-promotion
    CFLAGS += -Winit-self
    CFLAGS += -Wsequence-point
    CFLAGS += -Wfloat-equal

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

    CFLAGS += -Wc++-compat

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

enum COLOR
{
    RED = 0,
    GREEN,
    BLACK    
};

enum SPEED
{
    STOP = 0,
    SLOW,
    FAST    
};

void set_speed(enum SPEED v);

int main(void)
{
    set_speed(RED);
    ...
}

[vanner 0]

Так уж сложилось, что не привык писать юнит-тесты...

Зато считаю, что современные компиляторы имеют хорошие встроенные механизмы для статического (и синтаксического) тестирования.

 

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

[demiurg_spb 0]

А я и не путаю. Я лишь делюсь своими знаниями.

И, по-моему, внятно излагаю свои мысли. Если есть сомнения, перечитайте название топика и вопросы ТС в первом сообщении...

Я предложил вариант как улучшить качество кода. В чём вы сомневаетесь?

 

[kolobok0 0]

.. юнит-тесты используются для проверки логики...

 

это Вы немного путаете тёплое и солёное. :)

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

Хотя я могу ошибаться, посему опишите процедуру создания юнит тестов вам известных :)

 

[vanner 0]

А я и не путаю. Я лишь делюсь своими знаниями.

И, по-моему, внятно излагаю свои мысли. Если есть сомнения, перечитайте название топика и вопросы ТС в первом сообщении...

Я предложил вариант как улучшить качество кода. В чём вы сомневаетесь?

 

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

 

 

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

 

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

[kolobok0 0]

..задача модульного тестирования - это проверка корректности работы функции...

 

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

Именно этот момент(читай реализация) перечёркивает(порой) все не плохие начинания и идеи :)

 

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

 

[andrewlekar 0]

ну а теперь объясните тупому, как Вы предлагаете писать код-тест

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

void test_sum()
{
    ASSERT(5==sum(2, 3));
}

 

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

[vanner 0]

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

Именно этот момент(читай реализация) перечёркивает(порой) все не плохие начинания и идеи :)

 

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

 

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

Ну и не стоит забывать, что юнит-тесты это только одна из фаз тестирования системы.

[kolobok0 0]

Если мы пишем юнит-тест...

 

Речь была про организацию сего процесса.

Поясню...

Под словом "МЫ" - Вы кого конкретно описываете?

 

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

 

 

Смотрите выше, andrewlekar на пальцах объяснил...

 

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

 

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

 

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

 

Суть вопроса подчеркнул.

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

 

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