Фиктивный беда
У нас есть следующая проблема: ряд классов, к которым мы не можем прикоснуться, но которым необходимо их модульное тестирование, к сожалению, классы не предназначены для модульного тестирования, поэтому мы создаем фиктивные объекты для тестирования кода.
Пример:
class SomeOtherClass
{
public:
void foo2() { … }
};
class ClassToTest
{
public:
ClassToTest() {…}
void foo1() { SomeOtherClass A.foo2(); }
};
В приведенном выше примере мы хотели бы проверить foo1()
но это нужно foo2()
поэтому мы хотели бы сделать foo2()
принадлежат к фиктивному объекту (в реальной жизни эти функции / классы являются значительно более сложными и включают взаимодействие с аппаратными конфигурациями и т. д., таким образом, потребность в фиктивных объектах / функциях).
До сих пор мы делали что-то подобное, но это на самом деле не оптимально, потому что код, кажется, имеет побочные эффекты на других модульных тестах.
class MockSomeOtherClass
{
public:
foo2() { … } // mock function
};
#define SomeOtherClass MockSomeOtherClass
#include “ClassToTest.cpp”
...
Есть ли лучший способ сделать это без изменения исходных классов (или с минимальными изменениями)? Мы используем CPPUnit для тестирования.
РЕДАКТИРОВАТЬ: добавлен тег winapi для более четкого описания окружающей среды.
1 ответ
Существует продукт под названием Typemock Isolator++, предназначенный для решения проблем, которые вы подняли. Я еще не пробовал, поэтому не могу комментировать, насколько хорошо это работает или насколько легко / сложно его использовать.
К сожалению, вы должны дать им свой адрес электронной почты, чтобы попробовать это. Загрузка достаточно проста, но затем вы будете перенаправлены на эту страницу, на которой вам с радостью предлагается: "Зарегистрируйте свое программное обеспечение сейчас, чтобы получить БЕСПЛАТНУЮ пробную версию! Пожалуйста, введите свои данные, включая действительный адрес электронной почты, чтобы получить ключ активации для начала использования Isolator++."