Написание модульных тестов для кода C

Я разработчик С++, и когда дело доходит до тестирования, легко протестировать класс, введя зависимости, переопределяя функции-члены и т.д., чтобы вы могли легко проверить края. Однако в C вы не можете использовать эти замечательные функции. Мне сложно добавить модульные тесты для кода из-за некоторых "стандартных" способов написания кода C. Каковы наилучшие способы решения следующих задач:

Передача большого указателя структуры контекста:

void some_func( global_context_t *ctx, .... )
{
  /* lots of code, depending on the state of context */
}

Нет простого способа проверить отказ на зависимых функциях:

void some_func( .... )
{
  if (!get_network_state() && !some_other_func()) {
    do_something_func();
    ....
  }
  ...
}

Функции с большим количеством параметров:

void some_func( global_context_t *, int i, int j, other_struct_t *t, out_param_t **out, ...)
{
  /* hundreds and hundreds of lines of code */
}

Статические или скрытые функции:

static void foo( ... )
{
  /* some code */
} 

void some_public_func( ... }
{
  /* call static functions */
  foo( ... );
}

Ответ 1

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

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

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

Я лично использую TestDept, потому что он прост в использовании, облегчен и позволяет выполнять stubbing. Тем не менее, я не думаю, что он очень широко используется. Если вы ищете более популярную структуру, многие рекомендуют Check - это здорово, если вы используете automake.

Вот несколько конкретных ответов для ваших случаев использования:

Передача большого указателя структуры контекста

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

Нет простого способа проверить отказ на зависимых функциях

Я думаю, что это одно из самых больших препятствий с модульным тестированием C. У меня был успех с помощью TestDept, что позволяет выполнять время выполнения зависимых функций. Это отлично подходит для разрыва жестко связанного кода. Вот пример из их документации:

void test_stringify_cannot_malloc_returns_sane_result() {
  replace_function(&malloc, &always_failing_malloc);
  char *h = stringify('h');
  assert_string_equals("cannot_stringify", h);
}

В зависимости от вашей целевой среды это может работать или не работать. Подробнее см. их документацию.

Функции с большим количеством параметров

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

Статические или скрытые функции

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

 #include "implementation.c"

 /* Now I can call foo(), defined static in implementation.c */

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

Если вы работаете с устаревшим кодом, эта книга (Эффективно работает с устаревшим кодом Майкла Перса), это отличное чтение.

Ответ 2

Это был очень хороший вопрос, призванный заманить людей в убеждение, что С++ лучше, чем C, потому что это более проверяемо. Однако это вряд ли так просто.

Написав много тестируемых C + + и C-кодов, и одинаково впечатляющее количество незаменимых С++ и C-кода, я могу с уверенностью сказать, что вы можете обернуть crappy untestable code на обоих языках. На самом деле большинство проблем, которые вы представляете выше, одинаково проблематичны в С++. EG, многие люди пишут инкапсулированные функции без объектов в С++ и используют их внутри классов (см. Расширенное использование статических функций С++ в классах, например, таких как функции MyAscii:: fromUtf8()).

И я уверен, что вы видели gazillion функции класса С++ со слишком большим количеством параметров. И если вы считаете, что только потому, что функция имеет только один параметр, лучше, рассмотрите случай, что внутренне он часто маскирует переданные в параметрах, используя кучу переменных-членов. Не говоря уже о "статических или скрытых" функциях (подсказка, помните, что ключевое слово private: ") так же велико, как проблема.

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

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

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

Ответ 3

При модульном тестировании C вы обычно включаете .c файл в тест, чтобы сначала проверить статические функции перед тестированием публичных.

Если у вас есть сложные функции, и вы хотите протестировать их код, тогда можно работать с макетными объектами. Взгляните на cmocka модульную систему тестирования, которая предлагает поддержку макетных объектов.