Как к Ускорению тесты “единицы” WCF? (Создание/закрытие ServiceHost является медленным …),
Много других хороших решений здесь, но в интересах полноты:
echo *
4 ответа
Спасибо за все отличные ответы - все они содержат полезные указатели,
Я обнаружил, что многие мои тесты не закрывали алтарь клиента, это заставляло закрытие канала сервера ждать пока не истечет время ожидания TCP-соединения от клиента.
Это привело к увеличению скорости более чем в 10 раз.
Мы перестали писать интеграционные тесты, использующие WCF . Наладить и запустить всю систему в разумные сроки потребовалось слишком много усилий.
Вместо этого мы тестируем изолированную логику. Сериализация контрактов данных, которая является самым большим источником ошибок в этой области, также тестируется независимо от WCF (просто вызывая DataContractSerializer). После некоторых начальных усилий сам WCF до сих пор не создавал проблем.
Я не уверен, помогает ли это.
Изменить: Подумайте, что вы на самом деле тестируете.
- Какие ошибки вы ожидаете найти?
- Неужели нет другого способа проверить это? (например. мы нашли другой способ решения проблем с сериализацией)
- Насколько велика вероятность возникновения такого рода ошибок? Легко ли разработчикам избежать этого?
- Насколько сложно найти его путем ручного тестирования? (например, проблемы с сериализацией трудно найти, потому что может быть потеряно только одно свойство, с другой стороны, если клиент не может даже подключиться, его очень легко найти)
Если вы выполняете несколько тестов в своем Fixture, и если нет побочных эффектов, вы можете захотеть инициализировать хост раз и навсегда для всего приспособления, с
[FixtureSetup] и [FixtureTeardown] , поскольку [SetUp] и [Teardown] вызываются до и после каждые в вашем устройстве.
Кроме этого, интеграционное тестирование служб WCF всегда немного затруднительно ...
Мы делаем несколько подходов, в зависимости от того, какие функции WCF на самом деле входят в область проверки:
Если единственной необходимой функцией действительно является внешняя транзакция (как это произошло бы с [OperationBehavior (TransactionAutoCompete = true, TransactionScopeRequired = true)]) , то мы просто пишем оболочку для реализации службы, которая устанавливает и завершает транзакцию, как это сделал бы WCF. Затем мы вызываем эту оболочку и, следовательно, реализацию напрямую, то есть не через WCF.
Если требуются более сложные или расширенные функции, мы пытаемся хотя бы переключить транспорт на именованные каналы. Похоже, они на tat быстрее, включая открытие / закрытие.
Если даже параметры привязки / протокола важны, можно возразить, что по крайней мере теперь вы действительно занимаетесь интеграцией, а не модульным тестированием, YMMV. Но в любом случае в этом случае мы просто используем сервис как есть.