Возможны ли несколько сосуществующих экземпляров MockRepository? Если да, то при каких условиях?

Question

Возможны ли несколько сосуществующих экземпляров MockRepository? Если да, то при каких условиях?

Hippomocks’ MockRepository поддерживает несколько экземпляров, что касается компилятора. Однако некоторые варианты использования невозможны, так как они приводят к сбою исполняемого файла модульного теста. Давайте рассмотрим следующий пример.

void MyCall()
{
}

void MyCall2()
{
}

void MySubTest()
{
MockRepository mockRep2;
mockRep2.ExpectCallFunc(MyCall2);

MyCall2();
}

void MyTest()
{
MockRepository mockRep1;
mockRep1.ExpectCallFunc(MyCall);

MySubTest();

MyCall();
}

Этот пример приводит (в Visual C ++ 2010) к необработанному исключению (местоположение чтения нарушения доступа 0x00000048).

Анализ заголовка Hippomocks показывает, что этот вариант использования не предвидится (ср. MockRepoInstanceHolder). В чем причина разрешения только одного экземпляра?
Я могу понять, что, например, разные ExpectCallFunc в MockRepository случаи могут противоречить. Это причина этого?
Мы могли бы решить проблему в нашем примере, переместив mockRep1 инстанцирование после MySubTest() позвоните, но нам было трудно понять проблему в первую очередь. Есть ли возможность во время компиляции или во время выполнения явно идентифицировать такие множественные экземпляры?

0

c++hippomocks unit-testing

Решение

Другие решения

Я столкнулся с той же проблемой.
Используя cppunit в качестве тестовой среды, я сделал MockRepository членом класса тестовой рамки.
Если тестовых примеров несколько, cppunit создает новый объект класса тестового фрейма для каждого тестового примера. Это перезаписывает MockRepositoryHolder. Я получил исключение, пытаясь смоделировать функцию Windows API в первом тестовом примере, но HippoMocks ссылался на последний написанный MockRepository, который был одним из последних тестовых примеров.
Для меня обходной путь должен сделать MockRepository локальным для каждого теста или добавить новый локальный MockRepository только для насмешливых статических функций.

0

Источник

Accepted Answer

Основная проблема заключается в том, что функция (сгенерированная во время компиляции) не имеет возможности «пометить» ее определенным фиктивным хранилищем, и, в отличие от фиктивных объектов, ее также нельзя выращивать для переноса. Это то, для чего нужен держатель — чтобы найти фиктивный репозиторий из сгенерированной заглушки.

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

0