Imaginez deux serveurs (chacun dans un processus JVM) qui communiquent à l'aide d'une forme de messages (par exemple Producteur simple / consommateur)
J'aimerais écrire des tests d'unité qui testeront le comportement de ces deux serveurs. Y a-t-il des cadres (ou un addon Junit) pour ce problème? existe-t-il des S'il n'y a pas une approche de test de type unité, comment allez-vous tester de telles choses pendant une intégration continue?
Remarque:
Mes questions sont:
Je voudrais exécuter une classe de test Junit (ou même un seul test) dans un processus différent?
Il serait cool si un test unitaire peut facilement accéder aux variables de l'autre test (dans un processus différent) en utilisant une sorte de communication inter-processus.
Par exemple. J'aimerais Vérifiez si le producteur a vraiment produit les choses que je m'attendais, et ensuite, si le consommateur leur consommait. (et peut-être faire du flou pour détecter certains problèmes liés à la condition de race)
Je ne veux pas utiliser de threads, car cela peut modifier le comportement (si vous pensez aux problèmes de sécurité de thread-sécurité)
5 Réponses :
Je recommanderais d'utiliser des objets simulés, vous pouvez ensuite tester le producteur et le consommateur se moquant de manière indépendante l'autre. Donc, vous testez le producteur produit et que le consommateur consomme.
Vous pouvez également tester le mécanisme les deux communiquer, mais je m'attendrais à ce que cela soit fourni par une tierce partie?
Qu'est-ce que vous parlez au point 1 n'est pas un véritable scénario de test unitaire. Dans un test d'unité parfait, vous ne vous inquiétez pas pour qui produit les messages et qui consomment les messages. L'un de votre cas de test se concentrera sur l'imagination (ou la moqueur) que vous avez reçu différents messages d'un producteur valide et que vos cas de test vont tester la manière dont ils sont consommés correctement. Ce que vous cherchez, c'est plus comme un test d'intégration. Quoi qu'il en soit, certaines des déclarations que j'ai faites peuvent être subjectives. Vous pouvez utiliser JMock, Cadres EasyMock pour vos besoins moqueurs.
Ceci est bien au-delà des tests de l'unité et des tests d'intégration fermement à l'intérieur.
Je recommanderais de tester ce que vous pouvez en se moquant de votre couche de comms avec chaque pièce séparée.
Ce que j'ai fait dans le passé, dans de tels cas, c'est de démarrer un thread séparé dans le test qui commence un récepteur / expéditeur simulé. Dans le test principal, je fais ensuite la partie de l'expéditeur / récepteur. En pratique, cela signifie que cela est plein de retards pour vous assurer que les choses commencent dans le bon ordre et cela devient ralentissé, alors vous voulez simplement faire cela pour tester que les morceaux du puzzle s'adaptent et font aussi peu que possible des tests fonctionnels sur ça.
Je vérifie le comportement souhaité et terminez le fil d'assistance avant de quitter le test.
Cela peut tester beaucoup. Des tests utilisant des processus distincts (et des hôtes!) Est une vraie douleur. prend pour toujours et je limiterais cela aux tests manuels.
Je décrirais ce que vous cherchez à faire en tant que test d'intégration, et au-delà du champ d'application de JUNIT en tant que cadre (JUnit ne plongeant que son orteil dans des essais multi-threads, le multi-processus n'est certainement pas dans le jeu de caractéristiques. ).
Vous pouvez bien sûr utiliser Junit pour exécuter de tels tests, mais ils seraient vraiment limités à un coureur, le reste que vous devez faire vous-même.
D'autres ont déjà souligné le fait que vous vous moquez d'habituellement ou d'envoyer des méthodes construites artificiellement au consommateur et de tester ce que le producteur produit indépendamment au niveau "Test de l'unité".
en termes de tester en réalité l'interaction entre le producteur et le consommateur, une approche consiste à oublier les tests inter-processus et à tester intra-processus sur un thread via une sorte d'injection de dépendance où le producteur envoie le message. via une fausse façon qui le transmet juste sur le consommateur sans rien de plus sous la capuche que les appels de méthode in-thread.
Cependant, il semble que vous souhaitiez tester des choses qui puisse se produire avec les trucs inter-processus réels au-dessus de celui-ci (conditions de race et autres), ce qui rend ce tout-plus un test d'intégration.
Pour approcher ce problème, vous devez démarrer le processus et attendre l'acceptation d'un message, votre test indiquerait au producteur quel message créerait et il l'enverrait au consommateur. Ensuite, votre test demanderait au consommateur ce qu'il a obtenu (avec un retard approprié).
Le besoin ici devrait être convaincant pour moi de le faire. J'irais pour des tests d'acceptation automatisés pleins époustouflés et que cela englobe ce niveau d'intégration.
Vous devez jeter un coup d'œil à xHarness , que je crois satisfait à vos besoins. Je l'ai utilisé dans le passé récent et cela a fonctionné très bien pour nos projets à l'époque.
de sa page:
"xHarness est un harnais de test système pour Apache ant. Il permet aux développeurs de décrire leurs tests de produits / système dans la forme de XML dans le cadre d'une fourmi Construire un fichier, décrivant les tâches et processus qui comprennent les cas de test et quel est leur comportement attendu. Il a une puissante gestion de processus
capacités, qui étend le Tâches de processus de fourmis (EXEC, Java) à permettre exécution asynchrone de Java et processus natifs (par exemple pour Tests client-serveur), Synchronisation entre plusieurs processus et complexe Assertions sur le processus et la production de tâches (stdout / stardr, sortie de fichier, couplé avec des délais d'attente, etc.). "