J'ai juste besoin de tester des méthodes telles que ceci: Comment puis-je faire ça? Je peux appeler la méthode de démarrage et vérifier Isalive == True mais le thread continue de fonctionner en arrière-plan et appelle sa propre méthode. Une autre façon est que j'appelle démarrez et puis arrêtez-vous immédiatement, mais ce n'est pas une cause soignée, ce serait comme si je teste deux choses. C'est tellement simple mais arhh!
5 Réponses :
Utiliser Synchronisation de fil et Poignées d'attente Pour attendre sur les threads en cours d'exécution.
Pourquoi avez-vous besoin de tester ces méthodes? Qu'essayez-vous de vérifier? Est-ce que d'autres tests pausent si la chose que vous essayez de vérifier n'est-elle pas vraie? (C'est-à-dire qu'il est couvert par d'autres tests?)
Si non, vous pouvez entrer dans des sémaphores et que votre test d'unité garantit que le fil a commencé avant un délai donné, mais je ne pense tout simplement pas que ce soit un test extrêmement précieux à la fin. Cela n'augmenterait pas beaucoup de confiance.
C'est une bonne idée de faire des choses qui dépendraient de la synchronisation être synchrones aux fins des tests. (En effet, il est une bonne idée de localiser des interactions dépendantes du calendrier, même dans l'utilisation sans test.)
Si vous voulez vraiment simplement vérifier que ces méthodes commencent et arrêtent un thread, j'insérerais un objet factice Peut-être que votre situation est plus complexe que de simplement vérifier que le thread est démarré? Cela pourrait vous aider si vous avez posté un exemple légèrement plus grand du genre de chose que vous souhaitez tester. myTythread qui fournit ces méthodes mais ne démarre pas réellement un fil ou un fil dont Le code va juste s'asseoir et attendre sans rien faire. Ensuite, vous pouvez enregistrer que c'est démarré et arrêté, sans se soucier de la complexité de ce que fera votre fil réel.
Je suis d'accord avec Bnwasteland que, pour l'exemple de code donné, la seule chose que l'on puisse tester est ce système.Trreading.thread.Trread et System.threading.thread.Abort fonctionne correctement. Il serait donc raisonnable de supposer qu'ils sont et se concentrent sur le propre code de l'application. Ensuite, vous avez deux domaines:
1) Le code de tâche réelle qui s'exécute à l'intérieur du fil. Cela peut être testé dans un test d'unité normal.
2) Assurez-vous que l'infrastructure multithread fonctionne comme prévu.
(2) a plus de choses à la catégorie de test d'intégration, mais personne n'interdit à l'aide de la structure de l'unité-Tesitng pour cela. Et dans ce cas, il convient de faire démarrer / arrêter et même faire cela plusieurs fois avec certaines charges de travail randomisées pour vous assurer que le système se comporte et obtient le travail effectué. Cela passe évidemment dans une combinaison de test "plus longue" que vous ne voudriez pas vouloir exécuter à chaque enregistrement.
L'astuce consiste à séparer le comportement asynchrone de votre logique. Observez que votre logique réelle est synchrone et que la partie asynchrone est simplement un «temps d'attente» entre.
Le livre Les modèles de test Xunit le décrit bien. C'est même un modèle - objet humble . Il y est expliqué là-bas mieux que je peux.