Возможно ли в Qt для модульного тестирования (доступа) частных методов?

Правильный (читай раздражающий) ответ заключается в том, что вам не следует тестировать частные методы, это детали реализации ;-).

OTOH - вы думали об условном объявлении их защищенными/приватными в зависимости от того, находитесь ли вы в тестировании или нет, а затем расширяете? Я использовал это, чтобы вытащить меня из подобного зажима в прошлом.

#ifdef TESTING
// or maybe even public!
#define ACCESS protected
#else
#define ACCESS private
#endif

/* your class here */
class Foo {
ACCESS
    int fooeyness;
}

// or better yet, place this in a different file!
#ifdef TESTING
/*
    class which extends the tested class which has public accessors
*/
#endif

Решение 1, быстрое и простое: сделайте тестовый класс(ы) другом общедоступного.

class Foo {
   // ...
private:
   friend class FooTest;
};

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

Решение 2, также выполненное правильно: не помещайте частные методы в открытый класс, а создайте частный класс с общедоступными методами.

class Foo {
    // 
private:
    friend class FooPrivate;
    FooPrivate *d;
};

FooPrivate объявляется в своем собственном заголовке, который может быть не установлен, или оставаться в подкаталоге include-privates/ или что-то еще, т. е. он не мешает нормальному использованию. Таким образом, публичный класс остается чистым.

class FooPrivate {
public:
    // only public stuff in here;
    // and especially this:
    static FooPrivate *get(Foo *f) { return f->d; }
};

Затем тест включает закрытый заголовок и вызывает FooPrivate::get(fooObj) для получения экземпляра закрытого класса, а затем успешно использует его.

Я не согласен с менталитетом "частные члены - это детали реализации", который, на мой взгляд, примерно переводится как "тестировать только часть вашего кода".

Я могу относиться к аргументу «единицы есть единицы», но почему бы не попытаться покрыть как можно большую часть вашего кода тестами, даже внутри единиц? Ака. тщательное ректальное исследование ваших устройств.

И с учетом этого изображения один подход, который я часто использую и который не упоминается в других ответах, заключается в следующем:

1. Всегда объявляйте элементы, которые вы хотите протестировать, как protected вместо private в своем коде.
2. Подкласс вашего класса в тестовом коде и просто создайте нужные вам селекторы или просто напишите тестовый код непосредственно как члены в реализации этого подкласса.

ПРИМЕЧАНИЕ. Вы должны быть осторожны с классами, которые полагаются на сложные шаблоны создания экземпляров, чтобы убедиться, что вы создаете их правильно (читай: вызов конструктора исходного класса из подкласса ctor).

Я нашел более удобный способ сделать это. Во-первых, все приватные методы должны быть приватными слотами. Затем вы создаете экземпляр класса:

Foo a;

Затем мы можем использовать QMetaObject::invokeMethod для вызова любого слота, который есть у этого метода (открытого или закрытого). Итак, если мы хотим вызвать метод Test, мы можем сделать это так:

QMetaObject::invokeMethod(&a, "Test", Qt::DirectConnection);

Кроме того, у нас может быть возвращаемое значение и отправка аргументов... На самом деле все ответы здесь: http://doc.qt.nokia.com/stable/qmetaobject.html#invokeMethod

Я когда-то читал, что модульный тест должен тестировать общедоступный интерфейс класса, а не защищенный/частный материал.

Ваш класс должен просто вести себя правильно снаружи. Если стратегия реализации изменится, ваш класс Unit Test останется прежним.