¿Cómo acelerar las pruebas de "unidades" de WCF? (Crear/cerrar ServiceHost es lento ...)

Question

Estoy en el proceso de escribir algunas pruebas para un servidor que se implementa en WCF, ya que los mensajes son complejos y las llamadas se realizan a los clientes que deseo incluir WCF en las pruebas.

(Es posible que desee llamar a estos “ajuste” o “pruebas de integración”, no pruebas de unidad, el código en ambos lados del WCF tendrá más detalle prueba de unidad que no usan WCF.)

como mi servidor mantiene el estado y deseo para comprobar que todos los canales apagar sin errores, tengo un código como:

[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(); 
    } 

sin embargo mis pruebas son muy lento ....

¿Cómo se puede acelerar Iu p la creación y destrucción de mi ServiceHost?

Answer 1

Gracias por todas las respuestas grande - todos ellos contiene punteros votos,

he encontrado que muchos de mis pruebas no estaban cerrando la capilla mayor cliente, esto hace que el cierre de la espera canal de servidor hasta que la conexión TCP desde el cliente había agotado el tiempo de espera.

Ordenar esto condujo a un factor de aceleración de 10 veces.

Answer 2

Si está realizando varias pruebas en su Aparato, y si no hay efectos secundarios involucrados, es posible que desee inicializar el anfitrión de una vez por todas para toda la luminaria, con [FixtureSetup] y [FixtureTeardown], ya [SetUp] y [Teardown] se llaman antes y después de cada prueba en su dispositivo.

Aparte de eso, las pruebas de integración de los servicios de WCF son siempre un poco de dolor ...

Answer 3

Nos dejó de escribir pruebas de integración que usan WCF. Fue un esfuerzo excesivo hacer funcionar todo el sistema en un tiempo razonable.

En su lugar, estamos probando la lógica aislada. La serialización de los contratos de datos, que es la mayor fuente de errores en esta área, también se prueba independientemente de WCF (simplemente llamando al DataContractSerializer). Después de un esfuerzo inicial, WCF no causó problemas hasta ahora.

No estoy seguro de si esto ayuda.

---

Editar: pensar en lo que realmente se está probando.

• ¿Qué tipo de error esperas encontrar?
• ¿Realmente no hay otra manera de probarlo? (por ejemplo, encontramos otra forma de problemas de serialización)
• ¿Cuán grande es la probabilidad de que ocurra este tipo de error? ¿Es fácil para los desarrolladores evitarlo?
• ¿Qué tan difícil sería encontrarlo mediante pruebas manuales? (por ejemplo, los problemas de serialización son difíciles de encontrar, porque una sola propiedad podría perderse, por otro lado, si el cliente no puede conectarse, es muy fácil de encontrar)

Answer 4

Estamos haciendo varios enfoques , dependiendo de qué características de WCF están actualmente en el alcance de la prueba:

Si la única característica requerida realmente es una transacción ambiental (como ocurriría con [OperationBehavior (TransactionAutoCompete = true, TransactionScopeRequired = true)]), entonces simplemente escribimos un envoltorio alrededor de la implementación del servicio que configura y completa una transacción como lo haría WCF. Luego llamamos a esa envoltura, y por lo tanto a la implementación directamente, es decir, no a través de WCF.

Si se requieren características más complicadas o avanzadas, intentamos al menos cambiar el transporte a tuberías con nombre. Parece que son un tatuaje más rápido, incluyendo abrir/cerrar.

Si incluso las opciones de enlace/protocolo son importantes, se podría argumentar que, al menos ahora, realmente está haciendo integración y no pruebas de unidades, YMMV. Pero de todos modos en este caso, simplemente usamos el servicio tal como está.