Я видел много сумасшедших методов для получения доступа к частным переменным когда поблочное тестирование. Больше всего волнование, которое я видел, #define private public
.
Однако я никогда не видел, что любой предлагает выключить частные переменные на уровне компилятора. Я всегда только что предполагал, что Вы не могли. Я жаловался многим разработчикам, что поблочное тестирование было бы намного легче, если Вы могли бы просто сказать компилятору отступать для этого файла.
Затем я спотыкаюсь через -fno-access-control
Параметр компилятора GCC. Это так, очевидно, лучший способ к модульному тесту. Ваши файлы первоисточника не изменяются, никакие введенные друзья только для модульного теста, никакая перекомпиляция с причудливым волшебством препроцессора. Просто не щелкните 'никаким управлением доступом' переключатель при компиляции модульных тестов.
Я пропускаю что-то? Действительно ли это - серебряная пуля поблочного тестирования, я надеюсь, что это?
Единственным недостатком, который я вижу, является GCC-специфический-характер техники. Однако я предполагаю, что MSVS имеет подобный флаг.
Я бы сказал, что модульным тестам не нужен доступ к закрытым членам.
В общем, модульные тесты предназначены для тестирования интерфейса ваших классов, а не внутренняя реализация. Таким образом, изменения во внутреннем устройстве нарушат тесты, только если интерфейс был скомпрометирован.
Взгляните на мой ответ на аналогичный вопрос и последующее обсуждение. Конечно, это спорный вопрос, но это мои 0,02 доллара.
Обычно я стараюсь использовать в модульных тестах только открытый интерфейс моих классов. Здесь очень помогает разработка / проектирование, основанное на тестировании, поскольку результирующие классы, как правило, включают этот стиль модульного тестирования.
Однако иногда вам все же необходимо разрешить модульному тесту обращаться к не публичным членам, например, заменить содержимое синглтона на поддельный пример. Для этого я использую защиту пакетов в Java и друзей в C ++.
Некоторые люди, кажется, изгибаются назад, чтобы избежать друзей, но их следует использовать, когда это уместно, и их использование не ставит под угрозу дизайн. Они также декларативны и позволяют другим программистам знать, что вы делаете.