У меня есть класс, используемый для навигации вперед и назад по списку упорядоченных страниц. Страницы обычно, но не всегда доступны последовательно. Иногда одна или несколько страниц могут быть пропущены на основе определенных правил.
Для управления этим я поддерживаю два стека, вперед и назад, чтобы отслеживать, какие страницы ранее были посещены в любом направлении.
Что касается функциональности этого класса, то нет причин для его раскрытия. Однако при модульном тестировании методов навигации first(), next(), previous() и last(), которые все реорганизуют стеки и возвращают соответствующую страницу, мне нужно проверить, что стеки находятся в правильном "состоянии", в конце процесса.
Например, вызов first() должен привести к удалению прямого стека и каждой другой странице, которая ранее была посещена, чтобы быть перенесенной в задний стек.
Является ли это единственным достаточным основанием для предоставления геттеров для прямого и обратного стеков? Одной из причин, по которым я не решаюсь это сделать, является то, что я беспокоюсь, что это также подвергает их (возможно, непреднамеренным) внешним манипуляциям, которые могут привести к сбою в работе класса. Что делать, если клиент очищает стек, например?
UPDATE
Некоторые люди предположили, что этот вопрос является дубликатом опубликованного здесь. Я думаю, что два вопроса не совсем одинаковы. В другом вопросе обсуждается идея рефакторинга частного метода, чтобы сделать его общедоступным, чтобы проверить его. С другой стороны, этот вопрос, в частности, касается тестирования публичных методов путем изучения внутреннего состояния объекта в tes t. Я думаю, что там есть тонкая, но значительная разница, и принятый ответ ясно показывает, как тестировать одни и те же публичные методы, не изучая внутреннее состояние.