Qt test mock динамически связанная библиотека
Я немного запутался, как работать с фиктивными и динамически связанными библиотеками. Давайте предположим структуру проекта, подобную следующей
subdirs.pro (subdir project)
\- app (subdir project)
\-- app (executable, include and use lib)
\-- lib (dynamic library)
\- test (subdir project)
\-- test_app (test the app WITHOUT test lib again)
\-- test_lib (fully test of lib functions)
«Приложение» использует библиотеку; библиотека протестирована в рамках проекта test_lib.
Теперь я хочу протестировать приложение, но я не хочу снова тестировать всю библиотеку (что глупо и требует двойной работы без усилий!). Поэтому мне нужен какой-то способ издеваться над всей библиотекой. Кто-нибудь делал это раньше в Qt и может мне помочь? Возможно ли это в рамках Qt-теста? Я уже прочитал много статей и ТАК вопросов, но я не нашел решения этой особой проблемы.
Я использую Qt Creator 4.0.3, основанный на Qt 5.6.1, qmake с mscv2013 и включенной платформой для тестирования Qt.
Решение
Как я предлагал в комментариях, создать библиотеку, которая будет просто издеваться над API исходной библиотеки, вот как это можно сделать. Давайте предположим, что у вас есть класс Foo с некоторыми тривиальными API в нашей оригинальной библиотеке:
class Foo
{
public:
void doSomething();
int returnSomething();
private:
void doSometingElse();
};
Чтобы создать фиктивную библиотеку, вы должны следовать той же иерархии классов, что и в исходной библиотеке, сохраняя общедоступный API (закрытые и защищенные объекты можно игнорировать), чтобы приложение могло также компилировать и связываться с фиктивной библиотекой. Итак, наш Foo класс будет выглядеть так:
class Foo
{
public:
// This is just a stub
void doSomething()
{
// Do nothing
}
// This is just a stub
int returnSomething()
{
return 0; // Some value
}
};
Вам придется сделать один и тот же трюк со всеми классами, которые использует ваше приложение.
Если вы хотите создать приложение для тестирования, вы должны связать его скорее с фиктивной библиотекой, чем с оригинальной. Вам не нужно менять код приложения, но оно будет вызывать функции, которые ничего не будут делать.
ПРИМЕЧАНИЕ. Этот подход может не всегда работать должным образом, поскольку поведение вашего приложения может зависеть от того, как и какие функции библиотеки работают.
ОБНОВИТЬ
Другой подход заключается в сохранении отдельной библиотеки, однако условно создайте содержимое каждой общедоступной функции. С тем же образцом Foo класс в исходной библиотеке:
class Foo
{
public:
void doSomething()
{
#ifdef TEST_MODE
// Do nothing
#else
// Do things normally
#endif
}
int returnSomething()
{
#ifdef TEST_MODE
// Return some dummy value
#else
// Do the real calculations
#endif
}
private:
void doSometingElse();
};
Когда вам нужно создать приложение для тестирования, просто создайте библиотеку с TEST_MODE макрос препроцессора. При этом вы просто обойдете ненужное выполнение кода библиотеки.
Другие решения
Других решений пока нет …