2011-06-03 12 views
13

Dopo l'esecuzione di entrambi i seguenti casi di test, l'esecuzione COM viene stampata sulla console. Che cosa sto facendo di sbagliato?Eccezioni COM all'uscita con WPF

Se eseguo entrambi i test singolarmente o se eseguo entrambi i test insieme, l'eccezione viene scritta sulla console esattamente una volta. Questo mi fa sospettare che ci sia una sorta di risorsa per AppDomain che non sto pulendo.

Ho provato i test con NUnit e con MSTest, con lo stesso comportamento in entrambi gli ambienti. (In realtà, non sono sicuro se in esecuzione entrambi i test nei risultati MSTest in una sola eccezione stampa o due.)

Eccezione:

System.Runtime.InteropServices.InvalidComObjectException: COM object that has been separated from its underlying RCW cannot be used. 
at System.Windows.Input.TextServicesContext.StopTransitoryExtension() 
at System.Windows.Input.TextServicesContext.Uninitialize(Boolean appDomainShutdown) 
at System.Windows.Input.TextServicesContext.TextServicesContextShutDownListener.OnShutDown(Object target) 
at MS.Internal.ShutDownListener.HandleShutDown(Object sender, EventArgs e) 

Codice di prova:

using NUnit.Framework; 

namespace TaskdockSidebarTests.Client 
{ 
    [TestFixture, RequiresSTA] 
    public class ElementHostRCWError 
    { 
     [Test] 
     public void WinForms() 
     { 
      var form = new System.Windows.Forms.Form(); 
      var elementHost = new System.Windows.Forms.Integration.ElementHost(); 
      form.Controls.Add(elementHost); 

      // If the form is not shown, the exception is not printed. 
      form.Show(); 

      // These lines are optional. The exception is printed with or without 
      form.Close(); 
      form.Controls.Remove(elementHost); 
      elementHost.Dispose(); 
      form.Dispose(); 
     } 

     [Test] 
     public void WPF() 
     { 
      var window = new Window(); 

      // If the window is not shown, the exception is not printed. 
      window.Show(); 

      window.Close(); 
     } 
    } 
} 
+0

Forse http://social.msdn.microsoft.com/forums/en-US/vststest/thread/e53fdc45-23f3-4aee-aad9-f63769f2c638/ aiuta –

+0

Purtroppo, non posso usare MTA, come WPF richiede STA. Anche la creazione dell'host di modulo e elemento in SetUp non sembra fare il trucco. Argh. –

+0

Se non mi sbaglio, questa eccezione non causa il fallimento del test, vero? Ho riscontrato la stessa eccezione durante la disattivazione dei miei controlli WPF, ho scelto di ignorarlo ..;) – Bubblewrap

risposta

18

Guardando nuovamente il mio codice, la seguente riga potrebbe essere d'aiuto per il test WPF, proprio alla fine.

Dispatcher.CurrentDispatcher.InvokeShutdown(); 
+0

Sweeeeet! Questo è stato. Grazie! Ora ho solo bisogno di capire come adattarlo alla mia architettura di test. –

+0

Una volta che un dispatcher è legato a un thread (ad esempio, Dispatcher.CurrentDispatcher), nessun altro dispatcher può essere associato a quel thread. E una volta che un dispatcher è stato spento, non può essere riavviato. Quindi, mentre questo risolve il mio problema, purtroppo non posso semplicemente mettere una chiamata a InvokeShutdown() nel metodo TearDown della mia classe di test di base. –

+0

Provare a iniziare un nuovo thread STA in ogni unittest, eseguire il test in tale nuovo thread e attendere che quel thread termini con Thread.Join(). – Bubblewrap

1

Probabilmente si può 't unità testare le classi Window e Form affatto. Sia le applicazioni WinForms che le applicazioni WPF hanno una classe Application utilizzata per avviare l'impianto idraulico sottostante (pompe di messaggi e quant'altro). Scommetto che è la chiave per evitare questa eccezione.

Non ci stai e potrebbe non esserci.

Ogni raccomandazione per i test delle unità che abbia mai letto è che si refactoring in modo che le classi e FormWindow classi non fanno tutto il necessario per test di unità (come il modello M-V-VM in WPF). Potrebbe avere qualcosa a che fare con il fatto di non essere in grado di mostrare l'interfaccia utente.

Esistono altri modi per testare un'interfaccia utente. This answer discute l'interfaccia utente di test unità.

+3

In realtà, i test funzionano bene - ho finito con un sacco di schifezze nei miei file di registro. Per quanto riguarda i test dell'interfaccia utente rispetto ai test di logica aziendale - sono convinto che più mi avvicino alla verifica della cosa reale con cui l'utente si confronta, tanto meglio dormirò di notte. –

+0

+1 per Joel e Patrick, perché penso che tu abbia ragione entrambi. Mentre sono d'accordo con Joel sul fatto che il design dovrebbe essere così - non si può sostenere che a volte basta automatizzare alcuni controlli/finestre solo perché alcuni di quelli vecchi/fragili/meno recenti ne hanno bisogno. – quetzalcoatl