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

Question

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

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

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

Answer 1

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

Пример:

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

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

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

Answer 2

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

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

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

Answer 3

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

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