Включить mocking для модульного тестирования библиотеки в C

Question

В нашей среде мы сталкиваемся с проблемой, связанной с функциями имитации для наших библиотечных модульных тестов. Дело в том, что вместо насмешек над целыми модулями (. c файлами) мы хотели бы имитировать отдельные функции.

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

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

Мой подход теперь заключается в использовании атрибута функции weak при компиляции / компоновке библиотеки, чтобы компоновщик принимает фиктивную (неслабую) функцию при связывании с модульным тестом. Я уже проверил его, и он, кажется, работает как ожидалось.

Недостатком этого является то, что нам нужно много объявлений атрибутов в коде.

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

Теперь возникает вопрос: есть ли что-нибудь, что может сделать это хорошим способом?

Кстати: мы используем Clang 8 в качестве компилятора.

Answer 1

Джеймс Греннинг описывает несколько вариантов решения этой проблемы (http://blog.wingman-sw.com/linker-substitution-in-c-limitations-and-workarounds). Опция «Замена указателя функции» дает высокую степень свободы. Это работает следующим образом: заменить функции указателями на функции. Указатели на функции инициализируются так, чтобы указывать на исходную функцию, но каждый указатель может быть перенаправлен индивидуально на двойной тест.

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

Она также имеет определенную цену:

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