2015-07-08 1 views
0

Пожалуйста, обратите внимание на мой сценарий ниже,Как модульного тестирования, если метод изменяет только частный элемент и возвращает его

public class Test 
{ 
    private Tech tech = null; 

    ... 

    public Tech GetExpectedTech(string condition) 
    { 
     ... 

     return tech; 
    } 
} 

Я не уверен, что лучший способ сделать этот метод модульного тестирования. Может быть, я могу использовать отражение, но я не думаю, что это разумный путь. У кого-нибудь есть идеи?

+0

Я предлагаю прочитать [this] (http://stackoverflow.com/questions/1093020/unit-testing-and-checking-private-variable-value) –

+0

Для пуристов, тестирование модулей тестирования, а не код/​​реализация. Итак, что бы вы ни делали в своем методе и как вы это делаете, не важно в модульном тестировании. Это то, что метод делает и ведет себя в зависимости от ваших ожиданий. Поэтому вам не нужно заботиться о частных элементах. Если внутренняя реализация изменяется, но метод по-прежнему ведет себя как раньше, ваш тест (ы) не должен прерываться. – JoeBilly

ответ

0

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

Если побочным эффектом метода является то, что Tech хранится в поле класса, то вы должны делать это по какой-либо причине (если не вы этого не должны делать). В настоящее время нет причин в коде, который вы опубликовали, однако наиболее вероятная причина может заключаться в том, что в классе будут использоваться другие методы, которые используют этот Tech или возвращают его. В данный момент вы можете связать эти два метода, чтобы создать связь между этими двумя методами. Там нет ничего плохого с вызовом нескольких методов на вашем SUT, если отношения между методами является частью того, что вы пытаетесь проверить, так что вы можете сделать:

var expectedTech = sut.GetExpectedTech(someString); 
var otherTech = sut.DoSomethingElse(someOtherParams); 
Assert.AreEqual(expectedTech, otherTech); 

Если это взаимодействие с Tech, что вам нужно проверить для других методов вам может понадобиться посмотреть шаблоны создания, чтобы вы могли вводить Mock в свой SUT, но не зная, что еще делает ваш класс, трудно сказать, нужно ли это или нет.

Как вы уже сказали, вы можете получить доступ к элементу с помощью отражения, или PrivateObject, однако количество сценариев, в которых это правильная вещь, является относительно небольшим, поэтому, если вам нужно это сделать, это может быть знак что ваш класс нуждается в рефакторинге.

+0

спасибо для вашего незлого ответа. На самом деле, это класс построителя запросов, этот параметр является перечислением requestType, и этот класс реализует только интерфейс построителя запросов. Никакой другой метод в этом классе. – Allen4Tech

+0

@ AllenLi-AI3 Тогда звучит так, как будто ваш тест может заключаться в том, что если вы дважды вызовете метод, вы получите тот же экземпляр «Tech». В противном случае я не уверен, почему вы обновляете переменную-член. – forsvarir

+0

это не для обновления переменной-члена, это создает запрос на основе параметра requestType и возвращает его. – Allen4Tech