Je réutilise actuellement des tests Junit 4 d'un autre projet contre mon code. Je les obtient directement du référentiel du projet dans le cadre de ma construction automatisée de fourmis. C'est génial, car il assure que je garde mon code vert contre la toute dernière version des tests.
Cependant, il existe un sous-ensemble de tests que je ne m'attends jamais à transmettre mon code. Mais si je commence à ajouter @ignore annotations à ces tests, je devrai conserver ma propre copie séparée de la mise en œuvre des tests, que je Y a-t-il un moyen d'exclure des tests individuels sans modifier la source de test? Voici ce que j'ai regardé jusqu'à présent:
Autant que je puisse le constater, la tâche des ant Junit ne vous permet que d'exclure des cours d'essai entières, pas des méthodes de test individuelles - ce n'est donc pas bon pour moi, j'ai besoin de granularité de la méthode.
J'ai envisagé de mettre en place un test de test qui utilise la réflexion pour trouver et ajouter tous les tests d'origine, puis ajouter du code pour supprimer explicitement les tests que je ne veux pas exécuter. Mais j'ai abandonné cette idée quand j'ai remarqué que le API TestSuite ne fournit pas de méthode d'élimination des tests.
Je peux créer mes propres classes de test qui étendent les classes de test d'origine, remplacez les tests spécifiques que je ne veux pas exécuter et les annoter avec @ignore. Je courais ensuite Junit sur mes sous-classes. L'inconvénient est que si de nouvelles classes de test sont ajoutées au projet d'origine, je ne les ramasserai pas automatiquement. Je vais devoir surveiller pour de nouvelles classes de test car elles sont ajoutées au projet d'origine. C'est ma meilleure option jusqu'à présent, mais ne me sens pas idéal.
La seule autre option à laquelle je peux penser, c'est d'exécuter les mauvaises tests de toute façon et d'ignorer les échecs. Cependant, ces tests prennent un certain temps pour courir (et échouer!) Je préférerais donc ne pas les exécuter du tout. De plus, je ne peux pas voir une façon de dire à la tâche des ant d'ignorer les défaillances sur des méthodes de test spécifiques (à nouveau - je vois comment vous pouvez le faire pour les classes de test individuelles, mais pas des méthodes).
7 Réponses :
Si les tests indésirables sont dans des classes / packages spécifiques, vous pouvez utiliser un fichier de fichiers excluant dans la fourmi pour les exclure pendant l'importation.
Non, malheureusement, je dois exclure des méthodes de test spécifiques. C'est-à-dire que je veux courir des tests dans une classe de test donnée mais pas d'autres.
Si vous ne pouvez pas toucher le test d'origine à tout moment, vous allez avoir des limitations sérieuses. Vos sons primordiaux comme le meilleur pari, mais avec quelques changements:
Construisez les tests de fourmis exclusivement exclus des superches, de sorte que des classes supplémentaires que vous ne connaissez pas sur Get Run.
Vous pouvez utiliser l'annotation @rule (Nouveau sur Junit 4.7) pour savoir quel test est exécuté et l'abandonner (en renvoyant une mise en œuvre de la déclaration vide) plutôt que de remplacer des méthodes spécifiques, vous donnant plus de flexibilité pour savoir si Évitez le test. Le seul problème avec cette méthode est que vous ne pouvez pas arrêter les méthodes @Before à partir de cette méthode, ce qui peut être lent. Si tel est un problème (et que vous ne pouvez vraiment pas toucher les tests), alors @ignore dans la méthode de remplacement est la seule chose que je puisse penser.
Si, toutefois, vous pouvez toucher ces tests, certaines options supplémentaires s'ouvrent:
Vous pouvez les exécuter avec un coureur personnalisé en spécifiant la balise @Runwith sur la classe. Ce coureur passerait simplement sur l'exécution sur le coureur standard (junit4.class) dans ce projet, mais dans votre projet (via une propriété système ou un autre mécanisme) inspecterait le nom du test et ne pas exécuter un test. Cela présente l'avantage d'être le moins intrusif, mais le plus difficile à mettre en œuvre (les coureurs sont des bêtes velues, l'un des objectifs déclarés de @Rule consistait à éliminer la plupart des besoins de leur faire).
Un autre consiste à faire une déclaration assumée sur le test qui vérifierait un paramètre de configuration qui serait vrai si ce test devrait exécuter. Cela impliquerait réellement l'injection à l'essai dans le test, ce qui constitue probablement un disjoncteur de la transaction dans tout ce qui étipera un «projet séparé».
OK, il s'agit d'une solution plutôt épurée, mais ne me jette pas les choses si cela semble ridicule.
Le noyau de Junit4 est le Il est assez facile de créer des implémentations personnalisées d'un coureur et que vous les jetteriez normalement à l'aide de l'annotation Toutefois, en théorie, vous pouvez écrire votre propre tâche d'ant, sur la base de la tâche Standard Tound Junit, qui prend votre coureur de test personnalisé et l'utilise directement, en passant à chaque classe de test à son tour. Votre mise en œuvre de votre coureur pourrait utiliser un fichier de configuration externe qui spécifie les méthodes de test à ignorer.
Ce serait beaucoup de travail, et vous devriez passer du temps à creuser dans le code Junit préhistorique des fourmis pour savoir comment cela fonctionne. L'investissement dans le temps peut toutefois en valoir la peine.
C'est juste dommage que la tâche Junit Ant ne fournit pas de mécanisme pour spécifier le coureur de test, ce serait idéal. org.junit.runner.runner classe et ses différentes sous-classes, surtout org.junit.runners.suite . Ces coureurs déterminent ce que sont les tests pour une classe de test donnée, en utilisant des éléments tels que @Test et @ignore.
@Runwith sur vos classes de test, mais évidemment ce n'est pas une option pour vous.
Je dirais que la mise en œuvre d'un coureur est trompeuse simple. Je me suis retrouvé à copier et coller du code d'autres parties de Junit pour obtenir une personnalisation pour travailler correctement, et c'était très fragile - à peu près garanti de briser une nouvelle libération.
Tout vrai. Je n'ai jamais prétendu que c'était élégant :)
Une possibilité que je peux penser à réaliser ce que vous voulez avec les contraintes indiquées consiste à utiliser la modification de ByTecode. Vous pouvez conserver une liste de classes et de méthodes pour ignorer dans un fichier séparé et corrigez le bytecode des classes de test lorsque vous les chargez pour supprimer cette méthode.
Si je ne me trompe pas, Junit utilise la réflexion pour trouver les méthodes de test à exécuter. Une méthode Renommer le fonctionnement vous permettrait alors de supprimer ces méthodes avant que Junit les trouve. Ou la méthode peut être modifiée pour revenir immédiatement, sans effectuer une opération.
Une bibliothèque comme BCEL peut être utilisé pour modifier les classes lorsqu'elles sont chargées.
Junit 4 utilise des annotations au lieu de noms de méthodes pour déterminer les tests à exécuter.
Il serait toujours valide de modifier la méthode pour revenir immédiatement. Mais merci, je pensais à Junit3
Vraisemblablement, la modification de ByTecode pourrait également être utilisée pour ajouter @ignore Annotations aux méthodes des classes compilées.
Cela ne vous aide pas maintenant, mais Testg prend en charge ce type de capacité.
Si vous souhaitez exécuter uniquement un sous-ensemble des tests, cela ressemble à cette classe a plus d'une responsabilité et doit être refacturé. Alternativement, la classe de test pourrait être brisée de sorte que le projet d'origine ait tous les tests, mais sur une ou plusieurs classes (je suppose que certains tests sont vraiment des tests d'intégration et touchent la base de données ou le réseau) et vous pourriez exclure la classe ( es) vous n'avez pas voulu.
Si vous ne pouvez rien faire de cela, votre option de dépassement est probablement meilleure. Prenez le processus de chaque fois que vous devez ignorer certaines méthodes, vous étendez cette classe et l'ajoutez à votre liste d'exclusion de fourmis. De cette façon, vous pouvez exclure ce que vous ne pouvez pas passer et tirera toujours dans tous les nouveaux tests (méthodes que vous n'avez pas remplacés et de nouvelles classes de test) sans modifier votre construction.
Deux options