Разделительные Зависимости без инверсии управления

Question

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

Поскольку существует 600 проектов в нашей системе это кажется непрактичным переписать для использования инверсии управления. Typemock утверждает, что они являются единственной средой изоляции, которая doesn't require you to rewrite your code to use IOC.

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

Благодаря

Answer 1

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

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

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

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

Answer 2

Mocking non-virtual methods in C#

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

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

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

Answer 3

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

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

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

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

Answer 4

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

public class MotherClass 
{ 
    private SubClass _subClass; 

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

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

Это без IoC. Но с TypeMock Изолятор вы можете заменить его с помощью:

[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");