Удаление зависимостей при модульном тестировании процедурного кода

Question

В объектно-ориентированном языке с наследованием и виртуальными функциями удаление зависимостей (например, базы данных, вызовов API и т. Д.) Из кода модульного тестирования может быть таким же простым, как инкапсуляция этих зависимостей в их собственные методы и затем переопределение этих методов в тестовый класс, наследуемый от тестируемого класса.

Однако я столкнулся с проблемой при попытке сделать нечто подобное для процедурного кода (в частности, C). Без наследования я не могу переопределить эти вызовы, так как же обеспечить аналогичное удаление зависимостей при модульном тестировании процедурного кода?

Один из вариантов - предоставить альтернативы вызовам этих зависимостей и окружить их #ifdef s, но идеальным подходом будет применение модульного теста к тому же коду, что и в окончательной сборке. Это возможно?

Answer 1

Получите Эффективная работа с устаревшим кодом и прочитайте главу под названием «Мое приложение - это все вызовы API».

В основном, Перья описывает два варианта:

«Шов компоновщика»: вы можете скомпилировать в другом наборе реализаций вызовы API, которые вы пытаетесь заглушить, без необходимости изменять код - в основном измените makefile / .sln для компиляции в разных реализациях функций .

Если это не сработает, он говорит о «скине и обтекании», когда вы в основном перемещаете все функции API в абстрактный базовый класс, создаете два производных класса - производственную и реализацию модульного тестирования с переадресацией вызовов на соответствующие методы - затем используйте внедрение зависимостей, чтобы передать соответствующий набор функций.

Answer 2

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

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

Это немного проще сделать при работе с устаревшими API dbms или типичным API виджетов acme.

Для устаревших тестов я настоятельно рекомендую загрузить кран (протокол тестирования любого) из ccan и сохранить эти тесты изолированными.

Обычно 80% моих тестов нужно обернуть так, и это очень очень утомительно и неприятно поддерживать. Надеюсь, у вас есть только несколько странностей, с которыми нужно бороться.

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

Удачи, я действительно сочувствую.

Answer 3

Условная компиляция сработает, я сам делал это раньше. Тем не менее, требуется дисциплина, поскольку может возникнуть соблазн сказать, что «этот бит слишком сложно проверить», а затем просто не проверять его.

Другой вариант, на мой взгляд, заключается в создании специальных тестовых версий этих библиотек, содержащих ваши вызовы БД / API (они есть в библиотеках, не так ли?). Тестовая версия может поддерживать тот же интерфейс (очевидно, ручной процесс, поскольку у вас нет объекта / интерфейса для наследования), но будет обращаться к вашей платформе модульного тестирования и выполнять запросы через вашу платформу модульного теста. Я сделал то же самое для создания версий библиотек FitNesse, и не вижу причин, по которым он не может работать для модульных тестов.

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

Удачи!