Есть объект интерфейс которого необходимо протестировать. Сейчас все зависимости собираются методом контейнера BuildUp в самом объекте. Юнит тесты находятся в другой сборке. Необходимо подменить некоторые сервисы, в тестовой сборке, на заглушки.
Как кошерно конфигурировать и применять в таком случае контейнер ?

Здравствуйте, Dog, Вы писали:

Dog>Есть объект интерфейс которого необходимо протестировать. Сейчас все зависимости собираются методом контейнера BuildUp в самом объекте. Юнит тесты находятся в другой сборке. Необходимо подменить некоторые сервисы, в тестовой сборке, на заглушки.
Dog>Как кошерно конфигурировать и применять в таком случае контейнер ?
Сам объект вызывает BuildUp себя?
Такой вариант плохо тестируется и применяется он в основном для унаследованного кода пока в него внедряется IoC.

Dog>>Есть объект интерфейс которого необходимо протестировать. Сейчас все зависимости собираются методом контейнера BuildUp в самом объекте. Юнит тесты находятся в другой сборке. Необходимо подменить некоторые сервисы, в тестовой сборке, на заглушки.
Dog>>Как кошерно конфигурировать и применять в таком случае контейнер ?
G>Сам объект вызывает BuildUp себя?
G>Такой вариант плохо тестируется и применяется он в основном для унаследованного кода пока в него внедряется IoC.
Это я уже вижу Вопрос что с этим делать ?

Здравствуйте, Dog, Вы писали:

Dog>>>Есть объект интерфейс которого необходимо протестировать. Сейчас все зависимости собираются методом контейнера BuildUp в самом объекте. Юнит тесты находятся в другой сборке. Необходимо подменить некоторые сервисы, в тестовой сборке, на заглушки.
Dog>>>Как кошерно конфигурировать и применять в таком случае контейнер ?
G>>Сам объект вызывает BuildUp себя?
G>>Такой вариант плохо тестируется и применяется он в основном для унаследованного кода пока в него внедряется IoC.
Dog>Это я уже вижу Вопрос что с этим делать ?

Попытаться вынести сборку зависимостей на уровень выше — в код который содает данный класс.
Причем повторяя процедуру для каждого класса с BuildUp получится в итоге каноническое приложение с IoC. Я в своем блоге это описывал http://gandjustas.blogspot.com/2009/01/legacy-unity.html

G>>>Сам объект вызывает BuildUp себя?
G>>>Такой вариант плохо тестируется и применяется он в основном для унаследованного кода пока в него внедряется IoC.
Dog>>Это я уже вижу Вопрос что с этим делать ?
G>Попытаться вынести сборку зависимостей на уровень выше — в код который содает данный класс.
Некуда. Это wcf сервис

G>Причем повторяя процедуру для каждого класса с BuildUp получится в итоге каноническое приложение с IoC. Я в своем блоге это описывал http://gandjustas.blogspot.com/2009/01/legacy-unity.html
Если я всё же встану на тёмную сторону силы и напишу UnitySingleton то те сервисы, которые надо будет подменить в тестовой сборке, необходимо конфигурировать в xml ? Или можно как-то в run-time это сделать ?

зы. Просто все пишут, как круто использовать DI для тестирования, но как именно это дедают не пишут ... Не хочется изобретать велосипед.

Здравствуйте, Dog, Вы писали:

Dog>зы. Просто все пишут, как круто использовать DI для тестирования, но как именно это дедают не пишут ... Не хочется изобретать велосипед.

Раз уж согласны встать на темную сторону силы, может вам использовать TypeMock? Он и захардкоденные зависимости позволит мокать.

Здравствуйте, Dog, Вы писали:

G>>>>Сам объект вызывает BuildUp себя?
G>>>>Такой вариант плохо тестируется и применяется он в основном для унаследованного кода пока в него внедряется IoC.
Dog>>>Это я уже вижу Вопрос что с этим делать ?
G>>Попытаться вынести сборку зависимостей на уровень выше — в код который содает данный класс.
Dog>Некуда. Это wcf сервис

Да уж.
1)Идем в гугл, набиваем запрос "unity wcf"
2)получаем результат
3)Открываем первую и вторую ссылку и получаем решение

G>>Причем повторяя процедуру для каждого класса с BuildUp получится в итоге каноническое приложение с IoC. Я в своем блоге это описывал http://gandjustas.blogspot.com/2009/01/legacy-unity.html
Dog>Если я всё же встану на тёмную сторону силы и напишу UnitySingleton то те сервисы, которые надо будет подменить в тестовой сборке, необходимо конфигурировать в xml ? Или можно как-то в run-time это сделать ?
Для тестов вообще не обязательно контейнер использовать.

Dog>зы. Просто все пишут, как круто использовать DI для тестирования, но как именно это дедают не пишут ... Не хочется изобретать велосипед.
Не изобретай. При правильном построеннии DI сами компоненты не будут знать о контейнере. В тестах зависимости можно подпихивать руками.

Dog>>Если я всё же встану на тёмную сторону силы и напишу UnitySingleton то те сервисы, которые надо будет подменить в тестовой сборке, необходимо конфигурировать в xml ? Или можно как-то в run-time это сделать ?
G>Для тестов вообще не обязательно контейнер использовать.
Dog>>зы. Просто все пишут, как круто использовать DI для тестирования, но как именно это дедают не пишут ... Не хочется изобретать велосипед.
G>Не изобретай. При правильном построеннии DI сами компоненты не будут знать о контейнере. В тестах зависимости можно подпихивать руками.
Как ? Делать UnitySingleton описывать конфиг в xml и подпихивать в тестах свой конфиг ? Или ещё как-то... ?

Здравствуйте, Dog, Вы писали:

Dog>>>Если я всё же встану на тёмную сторону силы и напишу UnitySingleton то те сервисы, которые надо будет подменить в тестовой сборке, необходимо конфигурировать в xml ? Или можно как-то в run-time это сделать ?
G>>Для тестов вообще не обязательно контейнер использовать.
Dog>>>зы. Просто все пишут, как круто использовать DI для тестирования, но как именно это дедают не пишут ... Не хочется изобретать велосипед.
G>>Не изобретай. При правильном построеннии DI сами компоненты не будут знать о контейнере. В тестах зависимости можно подпихивать руками.
Dog>Как ? Делать UnitySingleton описывать конфиг в xml и подпихивать в тестах свой конфиг ? Или ещё как-то... ?
Нет, передачей параметров конструктору или присваиванием.

G>>>Не изобретай. При правильном построеннии DI сами компоненты не будут знать о контейнере. В тестах зависимости можно подпихивать руками.
Dog>>Как ? Делать UnitySingleton описывать конфиг в xml и подпихивать в тестах свой конфиг ? Или ещё как-то... ?
G>Нет, передачей параметров конструктору или присваиванием.
Что-то мне подсказывает, что такое прокатит только при паре простых зависимостей... А если у нас сложный случай, который конфигурируется именно контейнером ?

Здравствуйте, Dog, Вы писали:

G>>>>Не изобретай. При правильном построеннии DI сами компоненты не будут знать о контейнере. В тестах зависимости можно подпихивать руками.
Dog>>>Как ? Делать UnitySingleton описывать конфиг в xml и подпихивать в тестах свой конфиг ? Или ещё как-то... ?
G>>Нет, передачей параметров конструктору или присваиванием.
Dog>Что-то мне подсказывает, что такое прокатит только при паре простых зависимостей... А если у нас сложный случай, который конфигурируется именно контейнером ?

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

Dog>>Что-то мне подсказывает, что такое прокатит только при паре простых зависимостей... А если у нас сложный случай, который конфигурируется именно контейнером ?
G>Значит написано плохо. Не долно быть настолько сложных случаев, что без контейнера никуда. Все компоненты не должны зависить от реализаций других компонент, а только от интерфейсов, тогда при тестировании подменить реальную реализацию на мок-объект не представяет проблем.
т.е. иными словами, при тесте всё надо делать руками. круто
зы. Такое чувство, что те кто юзают контенеры так и делают и поэтому стыдливо молчат

Dog>т.е. иными словами, при тесте всё надо делать руками. круто
Dog>зы. Такое чувство, что те кто юзают контенеры так и делают и поэтому стыдливо молчат

Не фанат руками присваивать Dependency свойства. С одной стороны что мешает в тесте переконфигурировать UnitySingleton.Instance?

С другой не очень нравятся такие конструкции:

public AccountManager()  
{  
    UnitySingleton.Instance.BuildUp(this);  
}

А как смотрите на такой вариант?

private AccountManager()  
{  
}

public static AccountManager Create(IUnityContainer container)
{  
    var manager = new AccountManager();
    container.BuildUp(manager);  
    return mamnager;
}

Dog>>т.е. иными словами, при тесте всё надо делать руками. круто
Dog>>зы. Такое чувство, что те кто юзают контенеры так и делают и поэтому стыдливо молчат
SR>Не фанат руками присваивать Dependency свойства. С одной стороны что мешает в тесте переконфигурировать UnitySingleton.Instance?
Да мне вобщем всёравно руками или не руками. Мне интересны возможности и как это делаю те кто используют контейнеры и пишут тесты.
Руками для пары зависимостей вполне подойдёт.

SR>С другой не очень нравятся такие конструкции:
Singleton вообще не нравится. Если пишешь один, то нормально. Но если пишут несколько человек, то чем меньше публичных контрактов они могут использовать тем лучше. Иначе начинаеццо АДЪ.

SR>А как смотрите на такой вариант?
SR>

SR>private AccountManager()  
SR>{  
SR>}
SR>public static AccountManager Create(IUnityContainer container)
SR>{  
SR>    var manager = new AccountManager();
SR>    container.BuildUp(manager);  
SR>    return mamnager;
SR>}
SR>

А как мне подменить некоторые сервисы контейнере в тестовой сборке? Новый контейнер не предлогать

Здравствуйте, Dog, Вы писали:

Dog>>>Что-то мне подсказывает, что такое прокатит только при паре простых зависимостей... А если у нас сложный случай, который конфигурируется именно контейнером ?
G>>Значит написано плохо. Не долно быть настолько сложных случаев, что без контейнера никуда. Все компоненты не должны зависить от реализаций других компонент, а только от интерфейсов, тогда при тестировании подменить реальную реализацию на мок-объект не представяет проблем.
Dog>т.е. иными словами, при тесте всё надо делать руками. круто
Dog>зы. Такое чувство, что те кто юзают контенеры так и делают и поэтому стыдливо молчат
Так и делают и гордо молчат

Например приложение, описанное в моем блоге.
Зависимости очень простые


Тесты такие:

[TestClass]
public class SayHelloControllerTests
{
    SayHelloController controller;
    MockFactory factory;
    Mock<ISayHelloService> serviceMock;

    [TestInitialize]
    public void Setup()
    {
        factory = new MockFactory(MockBehavior.Default);
        serviceMock = factory.Create<ISayHelloService>();            

        //Какой ужас, я здесь зваисимости руками подпихнул
        controller = new SayHelloController(serviceMock.Object);
    }

    [TestCleanup]
    public void Cleanup()
    {
        factory.VerifyAll();
    }

    [TestMethod]
    public void IndexGetShouldRenderDefaultView()
    {
        var result = controller.Index();
        var viewResult = result as ViewResult;

        Assert.IsInstanceOfType(result, typeof(ViewResult));
        Assert.AreEqual(string.Empty,viewResult.ViewName);
    }

    [TestMethod]
    public void IndexPostShouldCallServiceAndReturnDefaultViewWithServiceResult()
    {
        var param = "Name";
        var retVal = "Return";

        serviceMock.Setup(s => s.SayHello(param)).Returns(retVal);

        var result = controller.Index(param);
        var viewResult = result as ViewResult;

        Assert.IsInstanceOfType(result, typeof(ViewResult));
        Assert.AreEqual(string.Empty, viewResult.ViewName);
        Assert.AreEqual(retVal, viewResult.ViewData.Model);
    }
}

И в чем проблема ручной сборки зависимостей для тестов?

Здравствуйте, Dog, Вы писали:

Dog>Да мне вобщем всёравно руками или не руками. Мне интересны возможности и как это делаю те кто используют контейнеры и пишут тесты.
Dog>Руками для пары зависимостей вполне подойдёт.
И для 5 подойдет, и даже для 10.
Это все равно получает меньше, чем конфигурировать контейнер.

G>И в чем проблема ручной сборки зависимостей для тестов?
Да нет проблемы. Иногда из тестовой сборки не всё видно.

Dog>>Руками для пары зависимостей вполне подойдёт.
G>И для 5 подойдет, и даже для 10.
G>Это все равно получает меньше, чем конфигурировать контейнер.
Уболтали

Здравствуйте, Dog, Вы писали:

Dog>Иногда из тестовой сборки не всё видно.

InternalsVisibleTo Attribute?

Здравствуйте, Dog, Вы писали:

G>>И в чем проблема ручной сборки зависимостей для тестов?
Dog>Да нет проблемы. Иногда из тестовой сборки не всё видно.
InternalsVisibleTo?