Внедрение зависимостей и модульное тестирование этого конструктора

Question

У меня есть конструктор и свойство в классе:

private IMyCollectionObjects _myCollectionObjects;

public MyClassConstructor(string message)
{
     _myCollectionObjects = MyCollection.GetCollectionObejects(message);
}

1. Как можно подробнее, помогите мне понять, как модульный тест этого конструктора и метод GetCollectionObjects?

2. Как мне полностью отделить классы? Вы можете дать ответ используя любой IoC, я хочу понять концепцию.

Спасибо.

Answer 1

Зависимости от статических элементов, таких как GetCollectionObjects, трудно проверить, потому что вы не можете заменить их реализацию во время выполнения. Это означает, что вы не можете полностью изолировать экземпляр MyClassConstructor от деталей реализации GetCollectionObjects. Без изоляции объекта тестирования его нельзя считать модульным тестом.

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

Вы можете изменить этот код, чтобы полностью отделить его (и, следовательно, полностью протестировать):

private readonly IMyCollectionObjects _myCollectionObjects;

public MyClassConstructor(IMyCollectionObjects myCollectionObjects)
{
    _myCollectionObjects = myCollectionObjects;
}

Это сводит на нет знания о том, как превратить сообщение в коллекцию прямо из MyClassConstructor, делая класс проще, более сплоченным и менее связанным.

Answer 2

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

Предполагая, что MyCollection является статическим классом, а GetCollectionObjects анализирует строку и возвращает IMyCollectionObjects, вам сначала нужно будет сделать MyCollection нестатичным и также передать его через конструктор. Статические классы / методы, используемые в классе, создают тесную связь, более или менее по определению.

Теперь вы будете создавать класс, передавая строку сообщения и MyCollection. Ваш конструктор использует их в комбинации для заполнения переменной-члена типа IMyCollectionObjects. Чтобы убедиться, что это происходит так, как ожидалось, вам понадобится способ проверить результат вне класса (то есть публичный метод). Поэтому вам понадобится средство получения свойств, которое предоставляет _myCollectionObjects.

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

Обратите внимание, что это действительно больше интеграционный тест, чем дискретный модульный тест. Вы действительно проверяете, что разбор прошел успешно. Если представленный здесь класс действительно является тем, что вы намереваетесь протестировать, то тест на самом деле будет просто проверять, чтобы GetCollectionObjects был и назывался . Результат этого вызова действительно не имеет значения, потому что у вас (предположительно) будет отдельный тест или набор тестов, которые гарантируют, что метод GetCollectionObjects в MyCollection работает должным образом.

Answer 3

В общем, модульное тестирование - это все унитарное тестирование, то есть, одно за раз.

Как можно больше деталей, пожалуйста, помогите мне понять, как модульное тестирование. этот конструктор и GetCollectionObjects метод?

Перво-наперво, проверил ли ты свой класс MyCollection? 1011 *

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

Как мне полностью отделить классы?Вы можете дать ответ, используя любой IoC, я хочу понять концепцию.

С моей скромной точки зрения, у вас должна быть четкая причина сделать объект зависимым от другого, используя внедрение зависимостей.Как только вы заставляете объект зависеть от другого, на мой взгляд, нет смысла их разъединять.Один из способов развязки может состоять в использовании Unity Application Block из Enterprise Library.

Модульное тестирование этого конструктора

Обычно при проверке такого типа вам нужно проверять только три вещи.конструктор.

1. то, что конструктор не возвращает нулевое значение;
2. то, что возвращаемый экземпляр имеет ожидаемый тип;
3. тот объект, который вы ожидаетесоздание экземпляра через свою зависимость фактически инициируется.

    [TestCase("message")]
    public void DependentConstructorTest(string message) {
        MyClassConstructor myclass = new MyClassConstructor(message);

        Assert.IsNotNull(myclass);
        Assert.IsInstanceOf(typeof(MyClassConstructor), myclass);
        Assert.IsNotNull(myclass.MyCollection); // Where MyCollection represents the property that 
                                                // exposes the instance created of the object from
                                                // which your MyClassConstructor class depends on.
    }

Примечание : этот тест написан с использованием атрибутов NUnit и методов утверждения.Используйте все, что вам нравится.