Доступ к приватным полям

Question

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

Мне нужно проверить конструктор моего класса, в конструкторе я установил экземпляр частного поля .. Так как мне проверить, не является ли это поле PRIVATE не нулевым?(потому что я предполагаю, что это то, что я должен проверить) -> Чтобы проверить:

 public BUDGET_MANAGER()
    {
        this.budget_provider = new BUDGET_PROVIDER();
    }

-> Тестовый метод:

    [TestMethod()]
    public void BUDGET_MANAGERConstructorTest1()
    {
        BUDGET_MANAGER target = new BUDGET_MANAGER();      
        Assert.IsNotNull(??,"the provider is not instancied");

    }

Как я могу это сделать?Спасибо за помощь, я довольно потерян в модульном тестировании ..

Answer 1

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

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

То, что вы тестируете, - это видимая функциональность, контракт или интерфейс.

Answer 2

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

Типичный тест вызывает конструктор, а затем вызывает открытое свойство илиметод и убедитесь, что результат соответствует ожидаемому.Тестирование таким образом означает, что если вы позже измените свою реализацию на (например) ленивое конструирование BudgetProvider только тогда, когда это необходимо, тогда все ваши тесты будут работать.Детали реализации, например, когда закрытый член имеет значение NULL или нет, не имеют отношения к клиентам вашего класса, и поэтому нет необходимости проверять его в ваших модульных тестах.

Answer 3

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

Почему вы хотите проверить сам конструктор? Было бы целесообразно проверить это, если есть какая-то логика . Например - вы создаете объект только в том случае, если заданные параметры верны, и вы делаете проверку перед созданием объекта. В противном случае создайте объект и убедитесь, что он ведет себя так, как ожидалось. Предположительно, если конструктор работает некорректно, поведение объекта также будет некорректным.

Также не поддавайтесь искушению выставлять закрытые поля как свойства только для проверки правильности их установки в конструкторе.

Answer 4

Если вы используете mstest, щелкните правой кнопкой мыши по исходному классу и нажмите создать тестовый метод доступа, выберите ваш тестовый проект.Затем проверьте это условие с помощью средства доступа (должно отображаться в intellisense).

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

Answer 5

Другие парни упоминали, что не следует делать при использовании юнит-тестирования.

Я попытаюсь найти способ сделать то, что вы хотите (вам все еще нужно проверить ваш конструктор):

public BUDGET_MANAGER()
{
    try
    {
        this.budget_provider = new BUDGET_PROVIDER();
    }
    catch {}

    if (this.budget_provider == null)
        throw new NullReferenceException("Budget provider is null !");
}