Альтернативы тестированию частных методов в TDD

Question

Я пытаюсь использовать TDD при написании класса, который должен анализировать XML-документ. Предположим, что класс называется XMLParser, а его конструктор принимает строку для пути к XML-файлу для разбора. Я хотел бы иметь метод Load(), который пытается загрузить этот XML в память и выполняет несколько проверок в файле, таких как ошибки файловой системы, независимо от того, является ли файл XML и т. Д.

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

У кого-нибудь есть хороший совет для такого сценария?

Answer 1

Предлагаю немного изменить архитектуру. В настоящее время у вас есть один класс высокого уровня с встроенной функциональностью с низким уровнем. Разделите это на несколько классов, принадлежащих к разным слоям (здесь я использую термин «слой»).

Пример:

1. Есть один класс с общедоступным интерфейсом вашего текущего класса. (-> слой высокого уровня)
2. Есть один класс, отвечающий за загрузку файлов с диска и обработки ошибок ввода-вывода (-> Низкий уровень слоя)
3. Пусть один класс, отвечающий за проверку достоверности XML-документов (-> Inbetween)

Теперь вы можете проверить все три этих класса самостоятельно!

Вы увидите, что ваш класс высокого уровня будет не намного больше, чем просто составление двух классов нижнего уровня.

Answer 2

Не используйте модификатор доступа (который является следующим до частного) и записывайте тест в том же пакете.

Хорошее OOD важно, но для действительно важного тестирования функциональности важнее. Хорошая практика всегда является лишь ориентиром, и они хороши в общем сценарии.

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

Answer 3

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

Public class TestableClass : MyClass 
{ 
    public someReturnType TestMethod() { 
     return base.PrivateMethod(); 
    } 
}