Должны ли непубличные функции быть проверены модулем и как? - PullRequest
8 голосов
/ 12 февраля 2009

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

Мой первоначальный вопрос: должен ли я стремиться к модульному тестированию и этих внутренних функций, поскольку они проще и, следовательно, проще для написания тестов? Мое инстинктивное чувство говорит, что да, что приводит к последующему вопросу, если так, как бы я поступил так в C ++?

Варианты, которые я придумала, - изменить эти внутренние функции с закрытых на защищенные и использовать либо класс друга, либо наследование для доступа к этим внутренним функциям. Является ли это лучшим / единственным способом сделать это, сохранив некоторую семантику скрытия внутренних методов?

Ответы [ 12 ]

0 голосов
/ 12 февраля 2009

Да, вы должны. Это называется тестирование белого ящика, это означает, что вам нужно много знать о внутренностях программы, чтобы правильно ее проверить.

Я бы создал публичные «заглушки», которые вызывают частные функции для тестирования. #ifdef заглушки, чтобы вы могли скомпилировать их после завершения тестирования.

0 голосов
/ 12 февраля 2009

Вы всегда можете использовать переключатель компиляции вокруг приватного: как

# если определено (UNIT_TEST)

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...