Выделение зависимостей без инверсии контроля - PullRequest
Новая
       26

Выделение зависимостей без инверсии контроля

3 голосов
/ 15 июля 2009

Я работаю над корпоративным приложением, которое сильно зависит от очередей сообщений, com +, баз данных, httpcontext, статических служебных классов и т. Д.

Поскольку в нашей системе 600 проектов, кажется, что нецелесообразно переписывать их с использованием инверсии управления. Typemock утверждает, что они являются единственной изолированной платформой, которая не требует от вас переписывать код для использования IOC .

Кто-нибудь знает, как TypeMock реализовал этот уровень функциональности и есть ли альтернативы? Даже если бы я переписал свое приложение, чтобы использовать инверсию управления, мне пришлось бы писать классы-обертки для очередей сообщений, httpcontext и т. Д. Для меня это звучит просто нелепо, я прав или нет, полагая, что Typemock - единственный жизнеспособный вариант для сценарий.

Спасибо

Ответы [ 4 ]

1 голос
/ 30 июля 2009

Если у вас есть такой класс: 

public class MotherClass
{
    private SubClass _subClass;

    public MotherClass()
    {
        _subClass = new SubClass();
    }
}

public class SubClass
{
    public string SomeMethod()
    {
        return "Hello";
    }
}

Это без IoC. Но с Typemock Isolator вы все равно можете заменить его: 

    [TestMethod]
    public void TestMethod()
    {
        var fake = Isolate.Fake.Instance<SubClass>();
        Isolate.Swap.NextInstance<SubClass>().With(fake);
    }

И даже обменять результат SomeMethod следующим образом: 

        var fake = Isolate.Fake.Instance<SubClass>();
        Isolate.WhenCalled(() => fake.SomeMethod()).WillReturn("Bye");
1 голос
/ 25 июля 2009

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

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

Для Java набор инструментов JMockit обеспечивает изоляцию для всех видов зависимостей без каких-либо необходимых изменений в производственном коде.

Внутри JMockit использует функциональные возможности, предоставляемые API java.lang.instrument. По сути, он позволяет методам / конструкторам переопределяться во время выполнения. Переопределение означает, что байт-код, реализующий метод / конструктор, заменяется. Это может быть сделано любое количество раз для одного и того же метода. Кроме того, классы могут преобразовываться во время загрузки (т. Е. Любой метод или конструктор, определенный в классе, может изменить свой байт-код непосредственно перед тем, как класс станет доступным для JVM).

1 голос
/ 15 июля 2009

Пересмешивание не виртуальных методов в C #

Без глубокого изучения, ответ - методы АОП. Поскольку вы можете перехватывать вызовы методов или изменять вызовы методов после этого, это делает возможным добавление фиктивных классов / экземпляров.

Это умное использование АОП.

Если вы хотите сделать это самостоятельно (и я уверен, что есть некоторые подводные камни ...), возьмите фреймворк Aspect Weaver с открытым исходным кодом: http://csharp -source.net / open-source / аспектно-ориентированная рамка

0 голосов
/ 15 июля 2009

Большинство фальшивых фреймворков полагаются на ту или иную форму МОК. Это потому, что МОК на самом деле является хорошей практикой. Помимо тестирования, представьте, что у вас есть класс, который ищет соединение с базой данных (а не вводит его), и теперь класс соединения с базой данных изменяется. Вам не нужно перекомпилировать свой код - вы должны просто иметь возможность изменить введенную зависимость. С точки зрения тестирования, вы можете сделать то же самое, внедрить фиктивный сервис базы данных.

Чтобы получить больше к вашему вопросу. Я бы сконцентрировался на постепенном рефакторинге для инъекций вместо жестко закодированной структуры поиска. Начните с больших частей, таких как базы данных и другие сторонние сервисы. Когда вы реорганизуете их, вы можете использовать любую фальшивую среду (я использовал EasyMock, и мне это нравится, но есть и другие - JMock, Mockito). Эти платформы не требуют классов-оболочек, но обычно полагаются на прокси-объекты. Когда вы создаете макет, вы фактически создаете прокси (который является экземпляром класса, над которым вы издеваетесь).

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

Наконец, вы можете посмотреть на такие языки, как Groovy. Groovy хорошо работает с Java (он компилируется в байт-код) и имеет встроенный макет прямо в язык. Некоторые поиски в Google для поиска фиктивных объектов в Groovy должны давать хорошие результаты.

...