Как ускорить «юнит» тесты WCF? (Создание / закрытие ServiceHost идет медленно ...)

Question

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

(Вы можете назвать эти «подходящие» или «интеграционные тесты» не модульными тестами, в коде по обе стороны WCF будет более подробный модульный тест, в котором не используется WCF.)

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

    [SetUp]
    public void SetUp()
    {
        //TODO find a fee port rathern then hard coding
        endPointAddress = "net.tcp://localhost:1234";

        mockEngineManagerImp = new Mock<IEngineManagerImp>();              

        EngineManager engineManager = new EngineManager(mockEngineManagerImp.Object);

        serviceHost = new ServiceHost(engineManager);
        serviceHost.AddServiceEndpoint(
            typeof(IEngineManager), 
            new NetTcpBinding(SecurityMode.None),
            endPointAddress);

        serviceHost.Open();      
    }

    [TearDown]
    public void TearDown()
    {
        serviceHost.Close();
    }

Однако мои тесты очень медленные ....

Как я могу ускорить создание и уничтожение моего ServiceHost?

Answer 1

Мы перестали писать интеграционные тесты, которые используют WCF. Это было слишком много усилий, чтобы заставить всю систему работать в разумные сроки.

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

Я не уверен, поможет ли это.

---

Редактировать: Подумайте о том, что вы на самом деле тестируете.

• Какие ошибки вы ожидаете найти?
• Нет ли другого способа проверить это? (например, мы нашли другой способ для проблем с сериализацией)
• Насколько велика вероятность возникновения такого рода ошибок? Разработчикам легко избежать этого?
• Насколько сложно было бы найти его при ручном тестировании? (например, проблемы с сериализацией трудно найти, поскольку может быть потеряно только одно свойство, с другой стороны, если клиент не может даже подключиться, его очень легко найти)

Answer 2

Спасибо за все отличные ответы - все они содержат полезные указатели,

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

Сортировка привела к увеличению скорости более чем в 10 раз.

Answer 3

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

Если единственной необходимой функцией действительно является внешняя транзакция (как это происходит с [OperationBehavior (TransactionAutoCompete = true, TransactionScopeRequired = true)]), то мы просто пишем оболочку вокруг реализации службы, которая устанавливает и завершает транзакцию как сделал бы WCF. Затем мы вызываем эту оболочку и, следовательно, реализацию напрямую, то есть не через WCF.

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

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

Answer 4

Если вы выполняете несколько тестов в своем приборе, и если нет побочных эффектов, вы можете инициализировать хост раз и навсегда для всего прибора, с [FixtureSetup] и [FixtureTeardown], поскольку [SetUp] и [Teardown] вызываются до и после каждого теста в вашем приборе.

Кроме этого, интеграционное тестирование служб WCF всегда немного болезненно ...