Come accelerare i test "unità" della WCF? (La creazione/chiusura di ServiceHost è lenta ...)

Question

Sono in procinto di scrivere alcuni test per un server implementato in WCF, poiché i messaggi sono complessi e vengono fatti richiami ai client che desidero includere WCF nei test.

(Si potrebbe desiderare di chiamare questi “fit” o “test di integrazione” non unit test, il codice su entrambi i lati della WCF avrà più prova di unità dettaglio che non utilizzano WCF.)

come il mio server tiene stato e vorrei controllare che tutti i canali chiusi senza errori, ho il codice come:

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

Tuttavia le mie prove sono molto lento ....

come posso velocizzare u p la creazione e la distruzione del mio ServiceHost?

Answer 1

Grazie per tutte le grandi risposte - tutti contiene indicazioni utili,

ho scoperto che molti dei miei test non stavano chiudendo il presbiterio cliente, questo rende la stretta sul attesa canale di server fino a quando la connessione TCP dal il cliente era scaduto.

L'ordinamento ha comportato un aumento del fattore 10.

Answer 2

Se si sta eseguendo diversi test nel vostro dispositivo, e se non c'è alcun effetto collaterale coinvolti, si potrebbe desiderare di inizializzare l'ospite una volta per tutte per l'intero apparecchio, con [FixtureSetup] e [FixtureTeardown], dal [SetUp] e [Teardown] vengono chiamati prima e dopo ogni test nel dispositivo.

Oltre a questo, i test di integrazione di servizi WCF sono sempre un po 'di dolore ...

Answer 3

Ci siamo fermati a scrivere i test di integrazione che utilizzano WCF. E 'stato troppo difficile rendere operativo l'intero sistema in tempi ragionevoli.

Invece, stiamo testando la logica isolata. La serializzazione dei contratti dati, che è la più grande fonte di errori in quest'area, è anche testata indipendentemente da WCF (basta chiamare DataContractSerializer). Dopo alcuni sforzi iniziali, la stessa WCF non ha creato problemi fino ad ora.

Non sono sicuro se questo aiuta.

---

Edit: pensare a quello che si sta effettivamente verificando.

• Che tipo di errori ti aspetti di trovare?
• Non c'è davvero nessun altro modo per testarlo? (ad esempio abbiamo trovato un altro modo per i problemi di serializzazione)
• Quanto è grande la possibilità che si verifichi questo tipo di errore? È facile per gli sviluppatori evitarlo?
• Quanto sarebbe difficile trovarlo con i test manuali? (ad esempio i problemi di serializzazione sono difficili da trovare, perché una sola proprietà potrebbe essere persa, d'altra parte, se il client non riesce nemmeno a connettersi, è molto facile da trovare)

Answer 4

Stiamo facendo diversi approcci , a seconda di quali funzionalità di WCF si trovano effettivamente nell'ambito del test:

Se l'unica caratteristica richiesta è in realtà una transazione ambientale (come accade con [OperationBehavior (TransactionAutoCompete = true, TransactionScopeRequired = true)]), quindi scriviamo semplicemente un wrapper sull'implementazione del servizio che imposta e completa una transazione come farebbe WCF. Quindi chiamiamo tale wrapper, e quindi l'implementazione direttamente, cioè non tramite WCF.

Se sono richieste funzionalità più complicate o avanzate, proviamo almeno a trasferire il trasporto su named pipe. Sembra che siano più veloci, tra cui aprire/chiudere.

Se anche le opzioni di binding/protocollo sono importanti, si potrebbe obiettare che almeno ora si sta davvero facendo integrazione e non test delle unità, YMMV. Ma comunque in questo caso usiamo semplicemente il servizio così com'è.