Test d'un blocage avec nUnit

Je suis novice en tests unitaires et nUnit (2.48). Je voudrais écrire une méthode de test où le cas d'échec est que ça se bloque. Est-ce possible? De toute évidence, nUnit ne sait pas par défaut combien de temps la méthode devrait prendre pour s'exécuter, donc devrais-je écrire du code pour faire le travail sur un thread séparé puis l'abandonner et lancer et exception si cela prend plus de temps? Y a-t-il une meilleure manière de faire cela?Test d'un blocage avec nUnit

Merci

Source

2009-01-23 xyz

C'est possible mais ce n'est peut-être pas la meilleure chose à faire. Les tests unitaires ne sont pas vraiment adaptés pour tester le comportement de concurrence, malheureusement, il n'y a pas beaucoup de méthodes de test qui conviennent.

NUnit ne fait rien avec les threads. Vous pouvez écrire des tests qui démarrent plusieurs threads, puis tester leur interaction. Mais ceux-ci commenceraient à ressembler plus à des tests d'intégration qu'à des tests unitaires. Un autre problème est que le comportement de blocage dépend généralement de l'ordre dans lequel les threads sont programmés. Il serait donc difficile d'écrire un test concluant pour tester un certain problème d'interblocage parce que vous n'avez aucun contrôle sur la planification des threads. est fait par le système d'exploitation. Vous pourriez vous retrouver avec des tests qui échouent parfois sur les processeurs multicœurs, mais qui réussissent toujours sur les processeurs mono-cœur.

Source

2009-01-23 12:39:44 Mendelt

Eh bien sa certainement possible de tester une impasse en exécutant votre code sur un autre thread et de voir si elle retourne en temps opportun. Voici quelques (très basique) exemple de code:

[TestFixture] 
public class DeadlockTests 
{ 
    [Test] 
    public void TestForDeadlock() 
    { 
     Thread thread = new Thread(ThreadFunction); 
     thread.Start(); 
     if (!thread.Join(5000)) 
     { 
      Assert.Fail("Deadlock detected"); 
     } 
    } 

    private void ThreadFunction() 
    { 
     // do something that causes a deadlock here 
     Thread.Sleep(10000); 
    } 
}

Je ne voudrais pas dire que c'est la « meilleure façon », mais il est celui que j'ai trouvé utile occasions.

Source

2009-01-23 12:38:11

http://en.wikipedia.org/wiki/Halting_problem – bl4ckb0l7

Et si la jointure venait après 5001 ms? – bl4ckb0l7

cela n'a rien à voir avec le problème d'arrêt. La clause «fashion time» s'en assure :-). Un problème avec ce test est qu'il ne teste pas vraiment les blocages, il ne fait tourner qu'un thread de test. Les blocages se produisent généralement en interaction entre les threads. – Mendelt

Jetez un coup d'œil à Microsoft Project appelé "Chess". Il est conçu pour trouver les bogues concordants http://research.microsoft.com/en-us/projects/chess/

Source

2009-01-23 12:43:31

La détection d'interblocage est équivalente à la halting problem, et donc actuellement non résoluble dans le cas général.

Si vous avez un problème spécifique à éviter, il peut y avoir des hacks spécifiques pour obtenir au moins un minimum de sécurité. Sachez cependant que cela ne peut être qu'un hack et jamais 100%. Par exemple, un tel test peut toujours passer sur la machine de développement mais jamais sur la machine de production.

Source

2009-01-23 12:47:42

Pour tester un blocage, vous devez implémenter un graphique d'état et une vérification des cycles dans votre graphique d'état actuel dans le test unitaire. Le graphe d'état comprend les ressources en tant que noeuds et les dépendances en tant qu'arêtes. Je n'ai aucune idée de la mise en œuvre d'une telle chose, mais c'est la théorie.

Un test unitaire teste l'exactitude de l'entrée et de la sortie des données (principalement pour le point suivant) et non l'exactitude du flux d'exécution de votre application.

L'idée de Mark Heath semble raisonnable, mais est académiquement erronée.

Source

2009-01-23 12:48:18 bl4ckb0l7

Test d'un blocage avec nUnit

Répondre

Questions connexes