Нет, если вы создаете экземпляр объекта типа ClassB
в контексте вашей тестируемой функции, компилятор (и компоновщик) удостоверится, что вы получите объект типа ClassB
;)
Вместо этого вы можете получить экземпляр вашего ложного класса, например, с помощью builder , фабричной функции или просто передать указатель на объект b
как параметр для Function()
.Таким образом, вы можете внедрить фиктивный объект при тестировании кода.
К счастью, мы говорим о C ++, так что есть еще один возможный способ: предоставить другое определение class ClassB
в случае, если ClassA::Function()
скомпилировано / скомпоновано в контексте теста.
Т.е. при построении теста вам нужно иметь другое "дерево сборки".Здесь вы можете обратиться к исходному файлу производительного дерева исходных текстов, содержащему проверяемый метод. Но вы можете включить другой заголовок с макетным определением ClassB
вместо производительного.В случае, если ClassB
определен в какой-то другой библиотеке, вы связываете его макетную версию.
Все это не относится к GMock.
То, что GMock может сделать для вас, кратко изложено вэто поваренная книга .Практически в любом случае можно увидеть, что создание фиктивного / фальшивого объекта выполняется в контексте тестового кодирования.Затем его необходимо каким-то образом «внедрить» в проверяемый код, как описано выше.