Tests unitaires, blocages et conditions de course

Question

Des suggestions sur la manière d'écrire des tests unitaires répétables pour le code susceptible de provoquer des blocages et des conditions de concurrence?

À l'heure actuelle, je suis enclin à sauter les tests unitaires et à me concentrer sur les tests de stress. Le problème, c’est que vous pouvez exécuter un test de stress cinq fois et obtenir cinq résultats différents.

EDIT: Je sais que ce n’est probablement qu’un rêve, mais s’il existait un moyen de contrôler des threads individuels et de les forcer à exécuter une instruction à la fois, j’irais peut-être quelque part.

Answer 1

Consultez TypeMock Racer (en version bêta)

modifier: effectivement Alpha

http://www.typemock.com/Typemock_software_deloppment_tools.html

Answer 2

Il est généralement possible de forcer les conditions de course prévues en utilisant des opérations telles que ManualResetEvent pour que chaque thread se trouve dans l'état attendu avant de le libérer, c'est-à-dire que le thread A dispose du verrou et attend la fin. un signal ... demande au thread B de demander le verrou, etc ...

Cependant, vous pouvez généralement écrire un tel test pour étudier un bogue suspect, pour prouver qu'il est corrigé et qu'il ne refait pas surface. Vous devez généralement définir les conditions de course (mais les tester aussi pragmatiques que possible).

Answer 3

Je ne pense pas que la recherche de conditions de course tombe vraiment dans le domaine des tests unitaires. Plus ou moins par définition, le seul moyen de tester les conditions de concurrence est de manière pseudo-aléatoire. Sauf si vous êtes prêt à vous efforcer de prouver formellement le bien-fondé de votre stratégie de verrouillage, vous devrez procéder à des tests de résistance.

Vous devez encore écrire des tests unitaires, afin de vérifier l'exactitude des algorithmes, plutôt que la stratégie de verrouillage.

Lors de tests de contrainte sur du code multithread, vous souhaiterez effectuer des tests dans des conditions où vous avez un processeur par thread, plusieurs threads partageant le même processeur et plus de processeurs que de threads (si possible).

Answer 4

Vous pouvez écrire une classe de verrou qui détecte les blocages potentiels en examinant l'ordre des opérations de verrouillage. Pour ce faire, nous avons un contexte de thread que tous les verrous enregistrent lorsqu’ils sont acquis (option pouvant être transformée en DEBUG uniquement).

L’idée est de créer un graphique où les nœuds représentent les verrous et un bord dirigé entre A et B signifie que "le verrou A était maintenu lors de l’acquisition du verrou B". Laissez votre programme s'exécuter avec des charges normales, puis vérifiez les cycles dans le graphique. Un cycle signifie qu'il y a un potentiel de blocage même si votre code ne l'a pas touché.

Answer 5

Je ne peux pas penser à un bon moyen automatisé, mais le mieux que je sois venu a été d’écrire un test unitaire qui «exposerait» une impasse, consistait à utiliser des points de rupture en plus d’un test unitaire. J'ai simplement ajouté des instructions sur l'endroit où ajouter le point d'arrêt. Des efforts manuels sont nécessaires, mais avec eux, vous pouvez toujours exposer votre programme de threads dans le cas le plus défavorable.

Peut-être que quelqu'un a trouvé un bon moyen d'automatiser ce type de fonctionnalité? Je pouvais imaginer exécuter automatiquement le débogueur, casser un thread sur une ligne spécifique, en laisser un autre s'exécuter jusqu'à une condition spécifique, puis faire une déclaration pour le test unitaire.

Answer 6

J'ai déjà utilisé des retards artificiels dans le code qui sont déclenchés par certains paramètres de la demande. Par exemple, une demande indique au serveur de différer l'écriture entre deux écritures et une autre de les traiter sans délai.

A écrit Mark Bessey, cela n’est utile que pour créer une repro, pas pour découvrir le problème.

Answer 7

Avez-vous essayé Corensic Jinx ?