Создание тестируемого кода

Question

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

Я хочу переопределить эти методы, чтобы исключить доступ к БД во время модульного тестирования.

Я подумал о следующих вариантах:

1. Превратить файл в класс и переопределить методы.
   Основным минусом здесь является то, что это приводит к множеству изменений по всей кодовой базе.
   Не идеально, хотя это улучшает код ...
2. Оберните весь исходный файл #ifdef PRODUCTION_CODE и создайте новый исходный файл, содержащий заглушку, и оберните его противоположным, то есть сделайте весь объект зависимым от компиляции. Проблема здесь в том, что в системе сборки, которая выполняет регрессионные тесты, мне пришлось бы компилировать дважды, один раз, чтобы создавать приложения и выполнять регрессионные тесты, и дополнительное время для создания исполняемых файлов модульного теста.

Какие-нибудь рекомендуемые способы сделать это?

Answer 1

Вы можете попробовать переопределить на уровне компоновщика. Имеют два разных файла .cpp, которые реализуют функции в заголовке, который описывает интерфейс БД - один вызывает реальную БД, другой вызывает поддельный интерфейс. Когда вы связываете для модульного тестирования, замените одно другим (могут помочь переменные, специфичные для целевых объектов в GNU make).

Answer 2

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

Вроде так:

 static DBAccessClass dac = new DBAccessClass ();

 void origFunction() { dac.origFunction(); }

А в тесте:

 dac = new DBAccessMockup();

Answer 3

1. Превратить файл в класс и переопределить методы. [...]
2. Обернуть весь исходный файл #ifdef [...]

Если возможно, переходите к 1, так как у вас будет централизованный способ обращения к коду базы данных (указатель класса вместо функций X). Это означает модульность, простоту в замене реализации (с заглушками или с другой серверной частью БД) и более инкапсулированный код.

Если вы выберете 2, рассмотрите возможность замены реализацией функций. То есть внутри исходных функций задействуйте код тестирования (на основе if).

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

Answer 4

Вы также можете посмотреть книгу Майкла Фезерса Эффективная работа с устаревшим кодом . Он не только обсуждает именно эти типы проблем, но и включает в себя множество примеров на C ++ (в дополнение к Java, C и C #). Перья также является первоначальным создателем CppUnit .