Обычно на этапе компоновки не происходит насмешка, а решается в вашем коде. Инъекция зависимости является одним из предпочтительных методов. То есть вы должны смоделировать свой код, чтобы иметь возможность выбирать между реальной и фиктивной реализацией.
Например, вы хотите создать объект A в своем коде. Одним из способов является создание двух разных реализаций A и ссылка на импровизированную реализацию при создании тестов. Подход Dependency Injection предполагает наличие указателя на интерфейс и передачу извне (например, в конструкторе) самого объекта. Затем из производственного кода вы пройдете реальный объект, а из модульного теста вы пройдете макет.
Если вам абсолютно необходимо сделать это на уровне ссылок и вы не можете избежать связывания «реальных» объектов, то можете ли вы обернуть эти объекты? Вот пример:
Предположим, это код, который вы хотите проверить:
void my_method()
{
ProblematicClass c;
c.Call();
}
ProblematicClass реализован в двух местах: один внутри SDK, другой - это ваш макет. Если вы можете заключить ProblematicClass в другой класс, вы можете создать два исходных файла:
Производственный файл:
struct Wrapper
{
public:
void Call() { m.Call(); }
private:
ProblematicClass m;
}
Файл макета:
struct Wrapper
{
public:
void Call() { m.Call(); }
private:
MockClass m;
}
Теперь источники находятся под вашим контролем, вам не нужно менять дизайн тестируемого кода, и вы можете исключить производственную реализацию. Ваш проверенный код, конечно, должен измениться на:
void my_method()
{
Wrapper c;
c.Call();
}