2008-11-02 15 views
11

In alcuni progetti, noto che durante l'esecuzione dei test delle unità in VSTS2008 la memoria di VSTestHost aumenta. Dato che ho molti test nella mia soluzione, alla fine mi porta a OutOfMemroyException. Questo per me è molto strano dato che ero sicuro che MSTest crea un nuovo AppDomain per ogni unit test. Altrimenti come resetterà i campi statici? Ma se AppDomain viene creato per ciascun test, la memoria non deve perdere. Ma lo fa.MSTest & AppDomains

Quindi la domanda è: VS deve creare AppDomain per ogni classe di test o no? Se sì di come posso verificare che lo faccia. Ho provato a tracciare tramite ProcessExpolorer e lo snap-in Prestazioni. Un valore di "Totale appdomain scaricati" è sempre 0 durante l'esecuzione del test.

+0

Ho lo stesso problema. Questo finì per essere un "problema tuo" come sembravano dire i rispondenti? O era in realtà il corridore di prova? Sono curioso. –

+0

Ho trovato http://social.msdn.microsoft.com/Forums/en-US/vststest/thread/2a2548b5-b992-4033-9d30-2f350a5aacaa/ e http://social.msdn.microsoft.com/ Forum/en-US/vststest/thread/95ac06fe-d595-4f49-b47a-bcdb667e65a1/- Mi viene l'idea che pochi di noi che hanno creato una suite di test di grandi dimensioni stiano riscontrando questo problema. –

risposta

7

Non penso che il motore di test dell'unità crei un nuovo AppDomain per ciascun test. Poiché la creazione di un AppDomain è un'operazione relativamente costosa, farlo per ogni test rallenterebbe notevolmente l'esecuzione dei test di unità!

Visual Studio 2008 utilizza un eseguibile separato denominato vstesthost.exe per eseguire i test delle unità. VS comunica con vstesthost.exe (come fa questo non so) per dirgli quali test eseguire. vstesthost.exe restituisce i risultati dell'esecuzione a VS che visualizza quei risultati.

Se si ottengono OutOfMemoryExceptions durante l'esecuzione dei test dell'unità, direi che è un forte indicatore del fatto che il codice in prova non risolve il problema. Sei sicuro di non mantenere le maniglie per oggetti/memoria non gestiti? Raccomanderei di eseguire i test dell'unità sotto un'analisi delle prestazioni (è possibile farlo trovando il test dell'unità sotto "Vista test", facendo clic con il pulsante destro del mouse su di esso e selezionando "Crea sessione di rendimento"). Questo potrebbe far luce almeno sull'assegnazione degli oggetti.

6

Ho sbagliato a disporre di AppDomain separati per ogni unittest.

Ecco la prova: un Singleton

public class Singleton 
{ 
    public static Singleton Instance = new Singleton(); 

    private Guid _token; 
    private Singleton() 
    { 
     _token = Guid.NewGuid(); 
    } 

    public Guid Token 
    { 
     get { return _token; } 
    } 
} 

e due test:

[TestClass] 
public class UnitTest2 
{ 
    [TestMethod] 
    public void TestMethod1() 
    { 
     Console.WriteLine(Singleton.Instance.Token); 
    } 
} 
[TestClass] 
public class UnitTest1 
{ 
    [TestMethod] 
    public void TestMethod1() 
    { 
     Console.WriteLine(Singleton.Instance.Token); 
    } 
} 

Durante l'esecuzione di entrambi i test in uscita lo stesso GUID.

10

MsTest crea il dominio one-app per Test assembly, a meno che non si utilizzi la noisolation, nel qual caso non è presente l'isolamento AppDomain.

Se si verificano perdite, è probabilmente un ma nel codice di prova o il codice del prodotto. Assicurati di non riempire le cose nei dizionari e di lasciarli lì.

+2

+1, dominio app per assembly. Ma crea anche una nuova istanza di una classe di test per test, quindi dovrebbe effettivamente GC i campi. Ho anche alcuni problemi di memoria con MS test e non so perché. Penso che ci siano alcuni problemi nel test runner. –

+1

+1 sull'istanza della classe di test per test. [ClassInitialize] è statico. – bryanbcook

1

Visto lo stesso problema con i test di grandi dimensioni. La mia teoria è la seguente. L'esaurimento della memoria in questo caso è dovuto al fatto che i file dei risultati dei test MSTest sono XML. Pertanto, è necessario conservare tutti i dati del registro in memoria fino alla fine dell'esecuzione del test prima della serializzazione su disco. Evviva per XML :-)

Ho postato questo problema come connect issue un po 'indietro e avrebbe dovuto essere risolto in MSTest 10 (andando a 64 bit) ma non ho potuto verificare questo ancora a causa di tutti altri problemi ci siamo trasferiti a VS2010 e .NET 4.0.

0

Questo non sembra essere risolto in MSTest 2010. Sto vivendo un sacco di problemi simili come questo. Perché la garbage collection non funziona nel test unitario?

La mia comprensione è stata che il framework UT si è occupato dello smaltimento di tutti i test eseguiti, ma questo non sembra essere il caso di alcuni pattern singleton che abbiamo nel codice.

0

L'unico modo per disporre di un singleton è di disporre dell'appDomain. Un singleton è una presa statica su se stesso, quindi è fondamentalmente un riferimento circolare. I veri singleton non vengono eliminati fino a quando l'appdomain non scompare.