Notre environnement de test possède une variété de tests d'intégration qui s'appuient sur le middleware (plate-forme CMS, sous-jacent DB, Index ElasticseSearch).
Ils sont automatisés et nous gérons notre middleware avec Docker, nous n'avons donc pas de problèmes avec des réseaux non fiables. Cependant, parfois notre DB se bloque et notre test échoue.
Le problème est que la détection de cette défaillance consiste à travers une litanie de Ma question: dans un environnement de test Java piloté par Maven, existe-t-il un moyen de diriger le système de construction afin de faire preuve de type spécifique d'exceptions et de tuer tout le processus, devrait-il arriver (ou atteindre une sorte de seuil)?
Nous pourriez-nous Watchdog nos conteneurs et tuer le processus de construction de cette façon, mais j'espère qu'il y a un moyen plus propre de le faire avec Maven. org.hibernate.exception.jdbcconnectionException Messages. Celles-ci viennent via un délai d'attente. Lorsque cela se produit, nous nous retrouvons avec des centaines de tests échouant avec cette exception, chacun prenant de nombreuses secondes à échouer. En conséquence, il faut un l'âge pour nos tests à compléter. En effet, nous venons généralement de tuer ces constructions manuellement lorsque nous réalisons qu'ils sont terminés.
4 Réponses :
Je ne sais pas si vous pouvez échouer, la construction elle-même, voire même - car les aspects administratifs de la construction peuvent ne pas compléter, mais vous pouvez le faire:
dans toutes vos classes de test qui Dépend de la base de données - ou des classes des parents, car quelque chose comme celui-ci est héritable - ajoutez ceci: Si la requête simple JDBC ne renvoie pas à 100 ms, la classe de test complète ne fonctionnera pas et montrera comme un "échec" à la construction. Faire le temps d'attente aussi petit que possible et toujours fiable.
Je me rends compte que ce n'est pas exactement ce que vous demandez, mais pourrait ne rien aider à accélérer la construction:
hypothèses Junit permet de laisser passer un test lors d'une L'hypothèse échoue. Vous pouvez avoir une hypothèse comme Afin de réellement accélérer les choses et de ne pas répéter cela encore et encore, vous pouvez la mettre dans un Une hypothèse d'échec dans une méthode @Before ou @Beforeclass aura le même effet qu'une hypothèse défaillante dans chaque méthode @Test de la classe.
de cause que vous devriez ensuite marquer votre construction aussi instable par une autre voie, mais cela devrait être facilement faisable. assuméhathat (db.isreduchable ()) qui sauterait ces tests lorsqu'un délai d'attente est atteint.
@classrule :
Si vous utilisez Testng au lieu de Junit, il existe d'autres possibilités de définir des tests aussi dépendants d'autres tests.
Par exemple, comme les autres mentionnés ci-dessus, vous pouvez avoir une méthode pour vérifier votre connexion de base de données et déclarer tous les autres tests Selon la dépendance de cette méthode. p> avec ceci, si le test code> ServerisSreachable code> échoue, tous les autres tests dépend de celui-ci seront ignorés et non marqué comme ayant échoué fort>. Les méthodes sautées seront signalées comme telles dans le rapport final, qui est importante puisque les méthodes sautées ne sont pas nécessairement des échecs. mais fort> depuis votre test initial Vous pouvez également étendre cette logique avec des groupes. Disons que vos requêtes de base de données sont utilisées par certains tests de logique de domaine, vous pouvez déclarer chaque test de base de données avec un groupe, comme p> et déclarer que vous déclarez des tests logiques de domaine aussi dépendants sur ces tests, avec P> ServerisSeaChable code> a échoué, la construction doit échouer complètement.
L'effet positif est que le non de vos autres tests sera exécuté, ce qui devrait échouer très rapide fort>. P> @Test(dependsOnGroups = { "jdbc.* })
public void domainTestOne() {}
Une chose que vous pourriez faire est d'écrire un nouveau test de test qui s'arrêtera si une telle erreur se produit. Voici un exemple de ce qui pourrait ressembler à: annotez vos classes de test avec . Fondamentalement, ce que cela est que cela vérifie une exception à une certaine exception (voici Il est également possible, qu'un comportement similaire pourrait être obtenu avec une règle @Runwith (stopafterspeciacersenceRunner.class) . Spéciiaxception , une exception que j'ai écrit moi-même) et si cela se produit, il échoue au test qui le jetait et saute tous les tests suivants. Vous pouvez bien sûr limiter qu'aux tests annotés avec une annotation spécifique si vous l'aimez.
Dupliquer possible de Stackoverflow.com/Questtions/1923857/...