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

[dea]

А у меня напротив опыт использования Unity на реальном железе. Огромный плюс — ее портабельность и минимализм: жужжит под win/wec7/linux/vxworks и с любым компилятором.

Правда признаюсь тесты — функциональные, unit тесты не осилили, а поэтому моки и раннеры не задействованы.

[0xFE]

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

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

[alexkalmuk]

Неплохая статья, на сайте Unity и правда все менее понятно.
Арсенал средств это CMock? Mock хорошая штука, и ребята молодцы, что пробуют добавить их в Си. Однако версия в Unity слишком уж урезана. По сути мы можем только проверить результат возврата (например, можно легко сэмулировать что в куче закончилась память). Но ведь моки чаще применяются когда дорого использовать реальные ресурсы типа БД, либо нужно быстро разработать прототип (не ясно как это сделать CMock'ом из-за его ограниченности).

[0xFE]

Арсенал средств это 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-ом.

[mend0za]

Делал презентацию для сотрудников Связка check + gcov + ggcov + make для TDD на С/Embedded Linux. Мешанина из unit-тестов и функциональных.

Плюсы подхода:

• Сразу в удобоваримом виде получаем результаты прогона и % покрытия кода тестами
• Очень легко найти мёртвый код
• Система компонентная. Можно менять сборку, утилиты для просмотра покрытия, etc
  


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

[0xFE]

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

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

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

How-To

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

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

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

[Amomum]

Other — под этим странным заголовком находится очень, полезный, на мой взгляд инструмент — CException. Невероятно маленькая библиотека для Си позволяющая получить некое подобие исключений. Но дезинформировать не буду. В проектах использовать не довелось.

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

[0xFE]

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

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

[Amomum]

Простите, но я по-прежнему не понимаю. Вы ей вообще пользовались или нет?

[0xFE]

Ответ на Ваш вопрос — нет.

[Amomum]

Понятно, спасибо.