Создание тестируемой службы WCF без OperationContext

Question

Я реализовал службу WCF подписки / публикации (для собственного удовольствия), которая работает достаточно хорошо. Как и все блоги и книги, которые я видел, все они используют OperationContext, чтобы получить адрес обратного вызова клиента. После небольшого прочтения, из-за того, что многие люди говорили, что не следует использовать OperationContext, я обнаружил, что не могу создавать надлежащие модульные тесты. Тем не менее я не смог найти альтернативу. Я полагаю, что метод подписки может принять параметр для него, чтобы предоставить свой собственный адрес? Я мог видеть, что код можно тестировать с точки зрения тестирования интеграции, но не для модульного тестирования, поскольку OperationContext всегда будет нулевым.

Как получить конечную точку клиентов, когда они подписываются на мою услугу, не используя OperationContext?

Немного обойдемся, но где хороший WCF-ресурс, нацеленный на тестирование при показе примеров кода? Существует множество блогов, повторяющих один и тот же код без предоставления примеров тестов.

Спасибо.

Answer 1

Разработчикам Microsoft действительно нравятся ключевые слова sealed и static (а также internal), и они ненавидят virtual. Из-за этого стандартные подходы к тестированию и фреймворки часто не работают. У вас есть два варианта:

1. Оберните доступ к OperationContext в пользовательском классе и добавьте экземпляр класса в свою службу. Это потребует дополнительной работы, потому что вам нужно будет делать инъекции где-то за пределами вашего обслуживания. Например, для инъекции в конструктор потребуются пользовательские IInstanceProvider.
2. Используйте более мощные рамки тестирования. Проверьте Moles Framework , который может перехватывать вызовы и перенаправлять их. Это позволяет «поддразнивать» запечатанные классы и статические методы / свойства.

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