2016-08-19 2 views
-2

Я пишу модульные тесты для своего класса и хотел бы использовать частные методы. Я делаю что-то вроде этого:C++ Модульное тестирование: изменение области действия

class MyClass { 
    Myclass() {} 
    ~MyClass() {} 
#ifdef TESTING 
public: 
#else 
private: 
#endif 
    void MyMethod1(); 
    void MyMethod2(); 
}; 

Если TESTING определено, изменить сигнатуру класса, чтобы сделать все общественности. В моем тестовом коде, я просто сделать что-то вроде этого:

#define TESTING 
#include "MyClass.h" 
void MyTestMethod() 
{ 
    MyClass mc; 
    mc.MyMethod1(); // Now I can access MyMethod1 
} 

так, что его только общественность в моих тестовых файлов, а не где-нибудь еще. Мой тестовый исполняемый файл видит заголовок, который описывает класс, который является общедоступным. Код для класса фактически строится где-то в другом месте (где TESTING не определен), поэтому область действия будет отличаться, если проект тестирования связан с библиотекой.

Имеет ли это возможность что-либо сломать? Я обеспокоен тем, что это может изменить местоположение vtables или ожидания компилятора и компоновщика, если заголовок отличается от того, что было фактически создано в объектном файле.

ответ

0

Ужасно, хотя это возможно, но не делайте этого, вместо этого создайте класс-оболочку для своих тестов и используйте ключевое слово friend TestClass; в MyClass.

+0

Я думал об этом, но тогда это затрудняет код рефакторинга, когда теперь вам нужно изменить две сигнатуры метода вместо одного. С помощью метода, который я описал, у вас меньше изменений и меньше классов для поддержки. –

+0

То, что указал Мартин, на 100% верно, однако, если вам все еще нужно это делать. Вы можете создать две версии MyClass, которые имеют одинаковое имя, но находятся в разных пространствах имен и имеют одну и ту же реализацию, но разные модификаторы доступа, а затем вы можете использовать директивы препроцессора и выбрать правильное пространство имен для использования в одной строке. –

5

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

Смежные вопросы