Юнит тесты на Си — нет ничего проще

Спасибо, будем иметь в виду. Такой арсенал платформ достоин внимания.

Думаю, что моки и раннеры тоже будут жить. Просто надо быть внимательным с инклудами (не включать лишнего) и не злоупотреблять printf() в чистом виде в надежде потом просто за-mock-ать <stdio.h> — framework-у тоже надо как-то печатать. Но это теория…

Арсенал средств это CMock?

+ CException — упомянут вскользь
+ Ceedling — позволяет мне писать только тест, не думая, как его запускать, где мой main, и как сделать сборку и запуск тестов автоматизированно на билд-сервере.
+ Ceedling Plugins — не упоминал, дабы не нагружать лишним. Цель статьи — максимально облегчить старт.

Хотя, может быть, Вы и правы, Арсенал — слово громкое.

По сути мы можем только проверить результат возврата

Это не всегда так. В моем примере функция без параметров. Но если, к примеру, у нас такой вариант:

// API that shall be mocked
int API_foo( int int_param, const char * str_param);

// tests
void test_another_foo()
{
  API_foo_ExpectAndReturn( 20, "expected string", 100 );
    
  API_target();
}

Тут мы ожидаем, что в результате вызова тестируемой функции API_target() будет вызвана за-mock-аная функция с параметрами 20 и «expected string» и в результате такого вызова mock вернет 100. Параметры тоже проверяются.
К тому же, если идет серия вызовов mock-ов, то порядок и количество вызовов учитываются.
Опять же — всего не расскажешь.

Но ведь моки чаще применяются когда дорого использовать реальные ресурсы типа БД, либо нужно быстро разработать прототип

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

Спасибо за материал.
Я сам фанат этого дела, и согласен с Вами в том, что покрытие — очень важный инструмент.

Минус — не хипстерский, пишем тесты руками. Никаких ruby и генераторов тестов.

Так не в «шашечках» дело. Вы можете с успехом пользоваться gcov и на Ceedling. Есть плагин для этого.

How-To

• в project.yml в самом низу находим и добавляем
  

  :plugins:
    :enabled:
      - gcov  # add this line
  

  
  
• вместо rake test:all используем rake gcov:all
  
• ищем артефакты в build/gcov (если мне не изменяет память)
  

Если вы не использовали эту штуку, то почему вы пишете, что она очень полезная?

К сожалению, далеко не все зависит от моих предпочтений. Иногда, клиент против, иногда мое руководство, иногда коллеги.
Я бы с огромным удовольствием обкатал это дело на настоящем проекте, но пока приходится выгребать "Old surly error handling".