Модульное тестирование пользовательских расширений WCF, таких как пользовательское поведение и инспекторы - PullRequest
Новая
       0

Модульное тестирование пользовательских расширений WCF, таких как пользовательское поведение и инспекторы

4 голосов
/ 02 апреля 2012

Для некоторых нужд я написал реализации IServiceBehavior, IEndpointBehavior, IDispatchMessageInspector, и все мои службы WCF используют их.

Нужно ли их тестировать? Если да, как мне выполнить модульное тестирование этих пользовательских точек расширения WCF? Я использую MSTest.

1 Ответ

0 голосов
/ 02 апреля 2012

У вас должно быть два набора тестов:

  1. Модульные тесты для ваших пользовательских реализаций этих интерфейсов
  2. Интеграционные тесты для ваших сервисов (которые также охватывают интерфейсы, но в сценарии полная настройка в реальном времени )

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

Однако обратите внимание, что есть два основных препятствия для успешного модульного тестирования таких реализаций битов WCF:

  • Заголовки контекста WCF (или просто поместить контекст в одиночку) будет трудно работать с точки зрения имитации, так как они происходят из статического класса ( OperationContext.Current )
  • Проверка некоторых параметров метода может быть невозможна, поскольку они запечатаны (например, InstanceContext ) или достаточно сложны

Естественно, все это можно преодолеть с использованием соответствующих приемов и инструментов:

  • Для закрытых классов, которые не будут работать с насмешками, вы просто создаете экземпляры (с помощью таких инструментов, как AutoFixture ) и настраиваете графы объектов / зависимостей вручную (это может занять много времени) , но в большинстве случаев вы не используете их все).
  • Все, что можно смоделировать / заглушить, должно быть сделано так: FakeItEasy давайте просто заглушим любой класс, если он не запечатан (не должен быть интерфейсом). Замечательно иметь дело с неиспользованными параметрами метода.

  • Чтобы справиться с OperationContext.Current (и подобным), вам, вероятно, придется немного изменить свой дизайн. Точно, все классы, использующие текущий контекст в некоторых отношениях, должны будут реализовывать метод protected virtual, предоставляющий его (или любую другую часть, которая может быть полезна, например, заголовки запроса): 

    protected virtual MessageHeaders GetContextHeaders()
{
    return OperationContext.Current.RequestContext.RequestMessage.Headers;
}

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

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

Дополнительное примечание : модульное тестирование также можно выполнить более простым способом, однако вам также понадобятся платные инструменты (например, Typemock Isolator , которые позволяют вам высмеивать статические / запечатанные классы ) и / или немного более тяжелые / сложные ( PEX / Moles ).

...