139 votes

Meilleure pratique: Initialiser les champs de la classe JUnit dans setUp () ou lors de la déclaration?

Dois-je initialiser les champs de la classe lors de la déclaration de ce genre?

public class SomeTest extends TestCase
{
    private final List list = new ArrayList();

    public void testPopulateList()
    {
        // Add stuff to the list
        // Assert the list contains what I expect
    }
}

Ou dans le setUp() comme ceci?

public class SomeTest extends TestCase
{
    private List list;

    @Override
    protected void setUp() throws Exception
    {
        super.setUp();
        this.list = new ArrayList();
    }

    public void testPopulateList()
    {
        // Add stuff to the list
        // Assert the list contains what I expect
    }
}

J'ai tendance à utiliser la première forme parce que c'est plus concis, et me permet d'utiliser final champs. Si je n'ai pas besoin d'utiliser la méthode setUp (), set-up, dois-je encore l'utiliser, et pourquoi?

Précisions: JUnit va instancier la classe de test une fois par la méthode d'essai. Cela signifie que list sera créé une fois par test, indépendamment de l'endroit où je le reconnais. Il signifie aussi il y a pas de dépendances temporelles entre les tests. Il semble donc qu'il n'y a pas d'avantages à l'aide de setUp(). Cependant JUnit FAQ a de nombreux exemples d'initialiser un vide de collecte dans le setUp(), donc je me dis il doit y avoir une raison.

107voto

Moss Collum Points 1316

Si vous vous demandez spécifiquement sur les exemples fournis dans la JUnit FAQ, tels que le test de base du modèle, je pense que la meilleure pratique d'être montré, il y a que la classe sous test doit être instancié dans votre méthode de configuration (ou dans une méthode de test).

Lorsque la JUnit exemples de créer une liste de tableaux dans la méthode de configuration, ils vont tous à tester le comportement de cette liste de tableaux, avec des cas comme testIndexOutOfBoundException, testEmptyCollection, et la comme. Le point de vue, il est de quelqu'un écrit une classe et s'assurer qu'il fonctionne.

Vous devriez probablement faire de même lors de l'essai de vos propres classes: créer votre objet dans l'installation ou dans une méthode de test, de sorte que vous serez en mesure d'obtenir une production raisonnable si vous cassez plus tard.

D'autre part, si vous utilisez un Java de la classe de collection (ou une autre bibliothèque de classe, d'ailleurs) dans votre code de test, ce n'est probablement pas parce que vous voulez le tester, c'est juste une partie de l'installation de test. Dans ce cas, vous pouvez supposer qu'il fonctionne comme prévu, afin de l'initialiser dans la déclaration ne sera pas un problème.

Pour ce que ça vaut, je travaille sur une assez grande, plusieurs ans, TDD-développé le code de base. Nous avons l'habitude d'initialiser les choses dans leurs déclarations dans le code de test, et dans l'année et demie que j'ai été sur ce projet, il n'a jamais causé de problème. Il y a donc au moins quelques preuves anecdotiques que c'est une chose raisonnable à faire.

51voto

Craig P. Motlin Points 11814

J'ai commencé à creuser moi-même et j'en ai trouvé un avantage potentiel de l'utilisation de setUp(). Si l'une des exceptions sont levées au cours de l'exécution du programme d'installation(), JUnit impression sera très utile trace de la pile. Sur l'autre main, si une exception est levée lors de construction de l'objet, le message d'erreur dit simplement JUnit était pas en mesure d'instancier le cas de test et vous ne voyez pas le numéro de la ligne où l'erreur s'est produite, probablement parce que JUnit utilise la réflexion pour instancier les classes de test.

Rien de tout cela s'applique à l'exemple de la création d'un vide de la collection, car qui ne sera jamais à jeter, mais c'est un avantage de la méthode setUp ().

21voto

Jurgen Hannaert Points 543

En plus Alex B de la réponse.

Il est même nécessaire d'utiliser la méthode de configuration pour instancier des ressources dans un certain état. Le faire dans le constructeur n'est pas seulement une question de timings, mais en raison de la façon JUnit exécute les tests, chaque test de l'état seraient effacés après l'exécution de l'un.

JUnit crée d'abord les instances de la testClass pour chaque méthode de test et lance les tests après chaque instance est créée. Avant l'exécution de la méthode d'essai, sa méthode d'installation est exécuté, dans laquelle un état peut être préparé.

Si la base de données de l'état serait créé dans le constructeur, toutes les instances d'instancier la db état de droit, les uns après les autres, avant l'exécution des tests. Le deuxième test, les tests exécutés avec un sale état.

JUnits cycle de vie:

  1. Créer un autre testclass instance pour chaque méthode de test
  2. Répétez l'opération pour chaque testclass exemple: configuration d'appel + appel de l'testmethod

Avec certaines exploitations forestières dans un test avec les deux méthodes de test, vous obtenez: (le numéro est le hashcode)

  • La création d'une nouvelle instance: 5718203
  • La création d'une nouvelle instance: 5947506
  • Programme d'installation: 5718203
  • TestOne: 5718203
  • Programme d'installation: 5947506
  • TestTwo: 5947506

7voto

dsaff Points 290

Votre champ d'initialiseurs sera exécutée une fois par la méthode d'essai avant de tout les tests sont exécutés. Aussi longtemps que vos valeurs de champ sont de petite taille en mémoire, peu de temps, et n'affectent pas l'état global, en utilisant le champ des initialiseurs est techniquement très bien. Toutefois, si ceux-ci ne détiennent pas, vous pouvez vous retrouver en consommant beaucoup de mémoire ou de temps la mise en place de vos champs avant le premier test est exécuté, et peut-être même à court de mémoire. Pour cette raison, de nombreux développeurs toujours définir des valeurs de champ dans la méthode setUp (), où il est toujours plus sûr, même quand il n'est pas strictement nécessaire.

Notez que dans JUnit 4, test de l'initialisation de l'objet qui se passe juste avant la marche d'essai, et donc, en utilisant le champ des initialiseurs est plus sûr, et a recommandé de style.

6voto

amit Points 4092

Dans votre cas (création d'une liste), il n'y a pas de différence dans la pratique. Mais généralement, il est préférable d’utiliser setUp (), car cela aidera Junit à signaler correctement les exceptions. Si une exception se produit dans le constructeur / l'initialiseur d'un test, il s'agit d'un échec du test. Toutefois, si une exception se produit lors de la configuration, il est naturel de penser que cela pose un problème lors de la configuration du test, et Junit le signale de manière appropriée.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X