J'ai trouvé que Static Block ne fonctionne qu'une seule fois lorsque j'exécute plusieurs tests Junit. Comment puis-je forcer à courir pour chaque méthode d'essai? J'utilise le dernier junit 4.8.2 également, selon Xunit Design Princile, chaque méthode doit être totalement indépendante sur d'autres. Pourquoi un bloc statique ne sera exécuté qu'une fois? Cela se produit même lorsque testmethod1 et testmethod2 sont dans les différentes classes de test .
5 Réponses :
euh ... faites-le non statique ? Vous pouvez également avoir des blocs d'initialisateur d'une instance (identiques à des blocs statiques, juste sans le mot-clé statique ). Mais le code de la configuration des tests devrait réellement entrer dans une configuration explicite ou @Before méthode.
Je pense que le point ici est de Test Initialisation statique via Junit, de ne pas désigner la classe testée. Ainsi, prouvez que chaque méthode statique, lorsqu'elle est appelée première (et donc chargée de la classe et provoquant l'init statique), fonctionne correctement. Pourrait être faux, cependant.
J'ai besoin d'un bloc statique pour que tous les objets partagent certaines choses courantes.
@user - Vous n'avez pas avoir à . Il y a d'autres moyens de partager des choses courantes.
Pourquoi le bloc statique ne sera exécuté qu'une fois?
Parce que c'est tout le point de blocs d'initialisateur statique!
ou pour le mettre d'autre moyen, si vous souhaitez que le code d'initialisation soit exécuté plusieurs fois, mettez-le dans un constructeur ou une méthode régulière, ou (dans un nombre minuscule de cas) un bloc d'initialiseur non statique.
Dans le contexte de Junit, la voie normale d'implémenter le démarrage de test et le code d'arrêt à l'aide de
Configuration () etdératrement () Méthodes.
Si vous essayez d'appuyer sur l'exécution de l'initialisation statique dans votre propre code, vous êtes pour une route difficile, je pense. Mais ensuite, des tests unitaires du code avec l'état statique (par exemple singletons) sont toujours difficiles ... et c'est l'une des raisons pour lesquelles les gens pensent que l'État statique est une mauvaise idée.
envisagez d'utiliser une injection de dépendance (alias inversion de contrôle) au lieu de singletons.
Alternativement, envisagez de modifier votre code d'initialisation singlets / statique pour faciliter la test de tester. Par exemple, ajoutez une méthode statique permettant à un test de ré-exécuter l'initialisation. (Et avant de dire que cela enfreint le modèle singleton: oui je sais. Vous devez choisir entre conception / implémentation "pureté" et facilité de test.)
Mais dans le cadre Junit, chaque méthode de test devrait être totalement indépendante d'une autre?
Chaque classe de test Junit peut avoir ses propres startup () et arrêt () . Si vous souhaitez que les méthodes de test soient totalement indépendantes, vous pouvez mettre chacun de l'autre dans sa propre classe.
@Stephen, modèle singleton est utile de temps en temps.
Oui ... mais cela présente également de graves problèmes pour les tests unitaires. Beaucoup de gens pensent que l'injection de dépendance offre une alternative plus propre aux singletons. C'est votre choix, mais la qualification est l'une des choses affectées par ce choix. Vous ne pouvez pas avoir les deux manières ...
@user: Si vous avez affaire à un singleton, vous auriez dû le dire.
@ user705414: correct. Cependant, une telle indépendance n'est possible que si le code est conçu pour cela. Et le code qui dépend des blocs d'initialisateur statiques ne joue pas bien avec des tests d'unités indépendants. Solution possible: déplacez le code de l'initialiseur statique en une méthode statique et appelez cette méthode à partir de l'initialisateur et des tests.
@user: C'est bien que vos tests soient tous totalement indépendants de l'autre - bon pour suivre les problèmes - mais irritant aussi cher. Si vous utilisez un peu un peu singuletons, vous pourriez être mieux à utiliser un cadre du CIO (par exemple, Spring) pour gérer la configuration et la gestion de la vie, et cela aidera également les tests.
Les blocs statiques ne sont exécutés que sur le chargement de la classe car c'est ce qu'ils sont: des initialisateurs de classe. Pour avoir un bloc statique, plusieurs fois, vous devez décharger la classe (pas une chose facile à faire ...).
Si vous devez utiliser des blocs statiques, vous pouvez proposer des moyens de les tester. Pourquoi ne pas déballer le bloc dans une méthode publique (statique)? Tout ce que vous avez à faire dans ce monde est de tester la méthode: Vous pourriez également être capable de vous éloigner avec un initialiseur ordinaire Bien que, la vérité est la plupart du code de la vérité ne nécessite pas d'utiliser des initialisateurs comme celui-ci du tout. EDIT: éteint Oracle aime l'approche de la méthode statique http://download.oracle.com/javase/tutorial/java/javaoo/initial.html
est le code statique pour les tests de la classe testée?
Si le code est statique, les tests peuvent donc partager, vous devez déplacer le code dans sa propre classe. Ensuite, soit le constructeur de la classe de test instancée d'une instance statique ou créez une suite de test qui fait la même chose.
Si vous voulez que chaque test soit seul, déplacez ce que vous faites dans votre bloc statique dans les méthodes de configuration () / TeReTown (), c'est ce qu'ils sont là pour.
Bloc statique n'est exécuté qu'une seule fois lorsque la première classe de temps est chargée dans JVM. Junit fournit et je souhaite exécuter un bloc statique de cette classe dans Junit avant de créer l'instance de voiture. Je dois charger cette classe dans @Before Annotation qui est essentiellement utilisé pour l'initialisation requise FRO Test Case. Ceci peut être utilisé pour exécuter des blocs statiques de classe. Par exemple, j'ai suivi de la classe voiture configuration () à l'aide de class.forname ("package.classname") code junit.
Pls montrer du code expliquant comment vous l'exécutez
Si vous voulez quelque chose d'initialisé avant que chaque @Test ne soit exécuté, faites-le dans une méthode annotée @Benement