Доступ к закрытым полям

Question

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

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

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

-> Test Mehod:

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

    } 

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

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 !"); 
}