JUnit: nouvelle instance avant d'invoquer chaque @la méthode d'Essai. Quels sont les avantages?
Actuellement, je suis à la lecture de "JUnit dans l'action" livre. Dans ce livre, j'ai trouvé le texte ci-dessous:
JUnit crée une nouvelle instance de la classe de test avant de l'appeler à chaque
@La méthode d'essai. Cela permet de fournir de l'indépendance entre les méthodes de test et de
évite involontaire des effets secondaires dans le code de test. Parce que chaque test
la méthode s'exécute sur un nouveau test de l'instance de classe, nous ne pouvons pas réutiliser exemple
les valeurs de la variable à travers les méthodes de test.
Maintenant je ne vois pas beaucoup de point dans cette démarche:
Par exemple:
public class CalculatorTest {
@Test
public void testAdd_1() {
Calculator calculator = new Calculator();
double result = calculator.add(1, 1);
assertEquals(2, result, 0);
}
@Test
public void testAdd_2() {
Calculator calculator = new Calculator();
double result = calculator.add(2, 2);
assertEquals(4, result, 0);
}
}
Pour la classe de test CalculatorTest il n'y a pas tous les avantages.
Ok, permet d'aller payer l'attention sur un autre exemple:
public class OneTest {
static byte count;
public OneTest() {
count++;
}
@Test
public void test1() {
System.out.println(count);
}
@Test
public void test2() {
System.out.println(count);
}
}
Pour la classe de test OneTest j'ai trouvé un moyen d'utiliser la même variable de comptage pour les nombreuses méthodes d'essai...
alors, Comment voir les vrais avantages de l'approche décrite dans le livre?
- Si vous parlez du "comte" champ de ensuite ses un champ statique. Ses une propriété de la classe, et non pas une instance spécifique. C'est pourquoi vous voyez le changement dans la valeur.
- vous devez récupérer votre réponse (et peut-être développer un peu plus, en montrant l'exemple avec un non-champ statique).
- premier exemple: nous n'avons aucun lien entre les méthodes de test. Dans ce cas, la création de la nouvelle instance de la classe de test pour l'exécution de chaque méthode de test - pas de sens. Un deuxième exemple: nous pouvons obtenir de "caractère non intentionnel effets secondaires" par le biais de variables statiques. :)), Où en sont les avantages?
- L'avantage est lorsque vous utilisez des variables d'instance et les modifier à l'intérieur de l'tests.
- C'est actuellement expliqué dans la documentation.
Vous devez vous connecter pour publier un commentaire.
Le but de l'instance distincte n'est pas pour tout avantage, mais de maintenir le contrat que chaque essai doit être exécuté indépendamment, sans aucun effet de l'exécution d'un test précédent. Il n'y a simplement pas d'autre moyen de s'assurer de ce contrat, autrement que par l'utilisation d'une instance différente pour chaque test.
Par exemple, le Printemps, la gestion des transactions permet de s'assurer de la restauration toutes les modifications apportées à la base de données par un test, par défaut, afin de maintenir le même contrat.
Donc, à l'aide de variables statiques dans un test est en général pas recommandée, car elle va à l'encontre de l'objet de l'une-par exemple-par-test pour avoir une ardoise propre pour chaque test.
Maintien de l'état de nettoyer entre les méthodes de test est utile pour les tests unitaires, mais est dans la manière, pour les tests fonctionnels, d'où le fait d'avoir des dépendances entre les tests est souvent nécessaire (par exemple, lorsque vous testez des pages web en utilisant le Sélénium, il est utile de ne pas déranger l'exécution de tests d'une certaine page si les tests de la page de connexion a échoué).
C'était l'une des principales raisons pour lesquelles j'ai créé TestNG, qui n'a pas d'instancier une nouvelle classe entre chaque méthode, par conséquent, vous donnant le choix au lieu d'imposer cette décision à vous.
TestNG prend également en charge les dépendances de tests, multithread tests, la notion de groupes ("seulement exécuter la servlet tests") et beaucoup plus de fonctionnalités.
Si vous testez une mutable classe, il y a une grande valeur de votre objet testé dans un état connu au début de chaque méthode de test, de sorte que l'ordre d'exécution de test n'a pas d'importance. La meilleure façon de faire qui consiste à créer une nouvelle instance de cette classe pour chaque test, et pour éviter les champs statiques.
Dans votre calculatrice exemple, il semble que votre
Calculator
classe est immuable et les résultats des appels de méthode ne dépendent que des paramètres. De sorte que le risque d'un test d'influencer l'autre est tout simplement pas là.Je n'arrive pas à voir le point de votre deuxième exemple. Vous avez écrit les méthodes annotées comme
@Test
que l'utilisation partagée de champ statique, mais vos méthodes n'ont pas d'affirmations, et ne sont pas vraiment tester quoi que ce soit.Si vous voulez faire de l'utiliser ou de champs statiques, en effet, pour conserver et de réutiliser une seule instance de la classe sous test, il est certainement possible de le faire, mais à faire vos tests de travailler et de rester indépendants les uns des autres requièrent plus de soins.