Как вы издеваетесь над Запечатанным классом?

Question

Mocking sealed classes может быть довольно больно. Я в настоящее время пользуюсь Adapter pattern, чтобы справиться с этим, но что-то вроде просто держится странно.

Итак, что лучше всего вы издеваетесь над закрытыми классами?

Ответы на Java более чем приветствуются. На самом деле, я ожидал, что сообщество Java уже справляется с этим и может предложить многое.

Но вот некоторые из .NET Мнение

• Why Duck Typing Matters for C# Develoepers
• Creating wrappers for sealed and other types for mocking
• Unit tests for WCF (and Moq)

Answer 1

Мое общее правило заключается в том, что объекты, которые мне нужно издеваться должны иметь общий интерфейс тоже. Я думаю, что это правильный дизайн и делает тесты намного проще (и обычно это то, что вы получаете, если вы делаете TDD). Подробнее об этом можно прочитать в блоге Google Testing latest post (см. Пункт 9).

Кроме того, я работал в основном на Java за последние 4 года, и могу сказать, что могу рассчитывать, с одной стороны, количество раз, когда я создал окончательный (запечатанный) класс. Другое правило здесь - я всегда должен иметь вескую причину, чтобы запечатать класс, а не запечатывать его по умолчанию.

Answer 2

Есть ли способ реализовать запечатанный класс от интерфейса ... и вместо этого имитирует интерфейс?

Что-то мне кажется, что с запечатанные классы неправильно, в первую очередь, но это только мне :)

Answer 3

Для .NET вы можете использовать что-то вроде TypeMock, которое использует API профилирования и позволяет подключаться к вызовам практически ко всему.

Answer 4

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

Я думаю, что если вы собираетесь использовать насмешливую структуру, вы должны использовать традиционную (например, Moq) и создать изолирующий слой вокруг нефиксируемой вещи и вместо этого высмеять изолирующий слой.

Answer 5

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

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

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

Для получения дополнительной информации см. this page.

Answer 6

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

Это также облегчает переход моих зависимостей в долгосрочной перспективе.

Answer 7

Совершенно разумно издеваться над закрытым классом, потому что многие каркасные классы запечатаны.

В моем случае я пытаюсь высмеять класс MessageQueue .Net, чтобы я мог TDD использовать мою грациозную логику обработки исключений.

Если у кого-то есть идеи о том, как преодолеть ошибку Мока относительно «Недействительной настройки для неперехваченного члена», пожалуйста, дайте мне знать.

код:

[TestMethod] 
    public void Test() 
    { 
     Queue<Message> messages = new Queue<Message>(); 
     Action<Message> sendDelegate = msg => messages.Enqueue(msg); 
     Func<TimeSpan, MessageQueueTransaction, Message> receiveDelegate = 
      (v1, v2) => 
      { 
       throw new Exception("Test Exception to simulate a failed queue read."); 
      }; 

     MessageQueue mockQueue = QueueMonitorHelper.MockQueue(sendDelegate, receiveDelegate).Object; 
    } 
    public static Mock<MessageQueue> MockQueue 
       (Action<Message> sendDelegate, Func<TimeSpan, MessageQueueTransaction, Message> receiveDelegate) 
    { 
     Mock<MessageQueue> mockQueue = new Mock<MessageQueue>(MockBehavior.Strict); 

     Expression<Action<MessageQueue>> sendMock = (msmq) => msmq.Send(It.IsAny<Message>()); //message => messages.Enqueue(message); 
     mockQueue.Setup(sendMock).Callback<Message>(sendDelegate); 

     Expression<Func<MessageQueue, Message>> receiveMock = (msmq) => msmq.Receive(It.IsAny<TimeSpan>(), It.IsAny<MessageQueueTransaction>()); 
     mockQueue.Setup(receiveMock).Returns<TimeSpan, MessageQueueTransaction>(receiveDelegate); 

     return mockQueue; 
    } 

Answer 8

Я считаю, что Moles от Microsoft Research, позволяет сделать это. На странице Moles:

Моль может быть использован для объезда любого .NET метода, в том числе невиртуальных/статические методов в запечатанных типах.

UPDATE: есть новая структура под названием «Подделка» в предстоящем выпуске VS 11, который предназначен для замены Родинки:

Fakes Framework in Visual Studio 11 является следующим поколением родинок & окурков, и в конечном итоге заменит его. Подделки отличаются от Moles, однако, поэтому переход от Moles to Fakes потребует внесения некоторых изменений в ваш код. Руководство по этой миграции будет доступно позднее.

Требования: Visual Studio 11 Ultimate, .NET 4.5

Answer 9

Хотя его в настоящее время доступна только в бета-версии, я думаю, что его полезным иметь в виду shim особенность нового Fakes framework (часть Visual Studio 11 Бета-релиз).

Типы прокладок обеспечивают механизм для обхода любого метода .NET определенному делегату. Типы прошивок генерируются кодом генератором Fakes, и они используют делегаты, которые мы называем shim-типами, чтобы указать новые реализации методов. Под капотом для прокладок используются обратные вызовы, которые были введены во время выполнения в методе MSIL.

Лично я смотрел на это, чтобы издеваться над методами на закрытых классах фреймов, таких как DrawingContext.

Answer 10

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

• Создать экземпляр закрытого класса без вызова конструктора.

• System.Runtime.Serialization.FormatterServices.GetUninitializedObject (instanceType);

• Присвоить значения для ваших свойств/полей с помощью отражения

• YourObject.GetType() GetProperty ("PropertyName") SetValue (DTO, новое_значение, нуль)..;
• YourObject.GetType(). GetField ("FieldName"). SetValue (dto, newValue);