Этот вопрос на самом деле не имеет никакого отношения к Ceedling (или Unity, CMock и т. Д. c), но я скорее думаю, что это пример интерпретации слова «unit» очень специфическим c способом . Краткая версия моего ответа заключается в том, что пример функции, которую вы здесь написали, на самом деле не представляет собой автономную «единицу», поэтому я бы сказал, что она на самом деле не является «модульной-тестируемой».
Только подумайте «функции» как «единицы», если это чистая функция или если вы можете найти подходящий стык (например, заглушки, шпионы или имитаторы для внешних интерфейсов)! В противном случае вам по необходимости придется проверять детали реализации внутри теста, что делает тесты очень хрупкими.
Чтобы иметь «единицу» тестируемого кода, вам нужно, чтобы оба могли видеть эффекты тестируемого модуля (например, сравнение возвращаемого значения и / или проверка других побочных эффектов) И, чтобы иметь возможность стимулировать тестируемый модуль (например, передавая аргументы в функцию или сначала настраивая некоторые побочные эффекты, которые модуль при тестировании полагается на).
Пример функции полагается на побочные эффекты некоторой другой функции (той, которая имеет побочный эффект изменения вашей stati c «глобальной» переменной), поэтому «правильный модуль» "в этом случае необходимо включить любую имеющуюся у вас функцию, которая вызывает эти побочные эффекты. Я предполагаю, что в вашем файле уже есть хотя бы одна такая функция, или ваш примерный код никогда не вернет ничего другого *.
* Это если только ваш пример не имеет побочного эффекта изменения самой переменной stati c. В этом случае должна быть как минимум функция, которая сбрасывает «глобальное состояние», иначе ваши тесты не будут изолированы друг от друга (т.е. их сложно сделать независимыми от порядка). Лучшим решением было бы явно показать зависимость вашего состояния с помощью аргументов func_under_test
, например func_under_test(struct some_opaque_type *state)
, и добавить функцию struct some_opaque_type *init_for_func_under_test()
.
TL; DR : If ваша функция не является чистой функцией (например, она полагается на скрытое состояние и / или сама имеет побочные эффекты) или если у вас нет соответствующих «швов» (например, заглушек или шпионов), тогда также включите функции, которые могут изменять скрытое состояние или проверять побочные эффекты в вашем определении тестируемого модуля .