Модульное тестирование и макетирование небольших, значимых классов в C ++

Question

Я пытаюсь настроить некоторые модульные тесты для существующего проекта C ++.

Вот настройки: Я выбрал Google Mock, который включает в себя Google Test. Я добавил еще один проект (называемый «Тесты») в решение Visual Studio. Устройства для тестирования находятся в другом проекте под названием Main. Планируется добавить каждый файл cpp, который я хочу протестировать, в проект Tests. Проект Tests имеет доступ ко всем заголовочным файлам из Main.

Я добавил один файл cpp в проект Tests, и он компилируется, но возникает ошибка компоновщика. Большинство из них из-за класса, производного от COleDateTime, называемого CTimeValue. Тестируемый модуль имеет методы с передаваемыми по значению параметрами CTimeValue, а также объявляет некоторые атрибуты CTimeValue.

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

CTimeValue - это только один из многих классов, подобных этому в проекте. Как я могу изолировать тестирование классов, которые используют эти пользовательские типы?

Ура, Феликс

Answer 1

Иногда нельзя просто насмехаться над вещами. В этом случае вы можете сделать всеобъемлющий тест для рассматриваемого класса (CTimeValue) и убедиться, что вы выполняете тесты для этого класса в качестве вспомогательного в другом тесте.

Answer 2

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

Answer 3

Используя фиктивный объект, вам нужно только добавить сигнатуры методов, которые использует ваше проверяемое оборудование, так что, возможно, вы можете создать макет, используя макет Google. Конечно, вам понадобится отдельный набор тестов для класса CTimeValue, и если он у вас есть, то, вероятно, лучше связать его с реальным объектом. Вам нужно решить, стоит ли это усилий, чтобы создать интерфейсный класс для создания макета.