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

[Муравей]

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

[cg_shura]

Смотрите в сторону юнит-тестирования, я для юнит-тестов на си использую 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);
}

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

Сообщение отредактировал cg_shura - Dec 4 2013, 17:48

[demiurg_spb]

Так уж сложилось, что не привык писать юнит-тесты...
Зато считаю, что современные компиляторы имеют хорошие встроенные механизмы для статического (и синтаксического) тестирования.
Достаточно почитать доку на компилятор и можно найти целый арсенал замечательных ключей (пример для 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]

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

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

[kolobok0]

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

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