2010-08-08 3 views
0

J'essaie de tester NUnit en ajoutant un élément à une collection à partir d'un nouveau thread. C'est la fonction de test que j'utilise:Erreur NUnit à l'index -1

[Test] 
public void WorkerThreadAccess() 
{ 
    string foo = "Foo"; 
    Collection<string> collection = new Collection<string>(); 
    System.Threading.Thread thread = 
       new System.Threading.Thread(() => collection.Add(foo)); 
    thread.Start(); 

    Collection<string> expected = new Collection<string> { foo }; 
    System.Threading.Thread.Sleep(0); 
    CollectionAssert.AreEqual(expected, collection); 
} 

Lorsque je lance le test une fois, il passe. Cependant, à chaque test ultérieur sans fermer GUI NUnit, NUnit ne l'Assertion avec une erreur bizarre:

Expected and actual are both <System.Collections.ObjectModel.Collection 1[System.String]`> with 1 elements
Values differ at index [0]
String lengths are both 3. Strings differ at index -1.
Expected: "Foo"
But was: "Foo"

Quelqu'un peut-il donner un aperçu de ce qui se passe mal? Les éléments me semblent identiques et index -1 ne doit être renvoyé que sur une erreur IndexOf().

EDIT: J'utilise NUnit 2.5.7

Répondre

1

essayez de remplacer System.Threading.Thread.Sleep(0); avec thread.Join();

Qu'est-ce que vous voulez vraiment est d'attendre le deuxième fil pour terminer, non seulement mettre en pause l'actuel .

+0

C'était exactement cela (et j'ai appris une nouvelle méthode). Pensez-vous que vous pouvez expliquer pourquoi céder mon fil a causé une erreur si la fonction a été appelée deux fois dans un processus? – bsg

+0

'Sleep (0)' renvoie simplement le contrôle au système d'exploitation (ou est-ce le processeur?), Qui choisit un autre thread de sa liste de threads actifs. Cela n'implique en aucun cas que votre deuxième thread sera choisi, ni que votre deuxième thread est terminé par le contrôle du temps est retourné à votre thread principal. Pourquoi l'exécuter une deuxième fois cause l'erreur, mais pas la première? Aucune idée ... Une sorte d'allocation de ressources/de compilation/de magie vaudou affectant la première exécution peut-être? Mais il est clair que votre 'collection' est toujours en cours de modification lorsque' CollectionAssert.AreEqual (expected, collection); 'est exécuté. –