Test de valeur par défaut et de définition dans le même test ou de séparer les cas de test

Recommanderiez-vous de faire l'un regroupement de cas de test dans @des méthodes d'Essai, ou d'avoir une @de la méthode de Test par test de scénario? Par exemple, supposons qu'il existe différentes façons de définir le contexte dans une application.

Est l'idée suivante acceptable?

@Test
public void testContextSetting() {
    //Test default setting
    assert(...)

    //Test setting a context variable
    assert(...)

    ...
}

Ou bien, voulez-vous suggérons plutôt de l'avoir comme ça, avoir chaque méthode atomique que possible:

@Test
public void textDefaultSetting() {
    //Test default setting
    assert(...)
}

@Test
public void testSettingContextVar() {
    //Test setting a context variable
    assert(...)

    ...
}

Tout commentaire serait apprécié.

InformationsquelleAutor Ariod | 2011-06-06
  1. 34

    Je préfère avoir un cas de test par la méthode.

    Abord, il est plus facile de voir quels sont les cas qui sont en train d'être testé si ils sont répartis dans les méthodes par opposition à la recherche de commentaires incorporés dans le code. La plupart des IDEs vous donnera un résumé des méthodes, donc au lieu de dire "j'ai test edgecase XYZ?" et puis la chasse pour un commentaire, ou à la recherche pour le code qui établit que edgecase, il vous suffit de regarder pour la méthode nommée setupContextEdgeCaseXYZ().

    Une deuxième raison est que si vous avez plusieurs cas on peut échouer et puis les autres n'exécutez jamais.

     testDefaultCase()
 testInvalidInput()
 testEdgeCase1()
 testEdgeCase2()

    Avec cette structure, il serait plus facile de déterminer que l'entrée de contrôle est mauvais et le bord de cas 2 n'est pas manipulée correctement, mais les autres sont OK (et il se peut qu'à défaut de deux affaires sont liées et le problème est diagnostiqué plus rapide).

    Une troisième raison est que vous risquez de laisser les valeurs à partir d'un précédent jeu de test qui annule un dernier essai dans un discret chemin. Un exemple simple:

    @Test
public void testMyMethod() {
  //test default
  String test = Foo.bar(null);
  assertEquals("foo", test);

  //test case 1
  Foo.bar(aValue);
  //Oops forgot to set value above, this passes regardless of 
  //what the above call does
  assertEquals("foo", test);
}

    Par la rupture des cas à part, vous pouvez éviter les erreurs comme ci-dessus comme qui serait à son tour tenu de la compilation d'erreur ou d'avertissement.

    • +1, Mais je vous propose une affaire dans laquelle il est préférable d'avoir un seul test: lorsque votre montage de test est dur et coûteux à l'installation.
    • Et bien sûr, si c'est un appareil qui peut être partagée entre différents tests.Dans ce cas, un simple test pourrait vous sauver de la configuration de l'appareil à plusieurs reprises. Souvent ce qui se passe dans les tests d'intégration où l'on utilise des bases de données en mémoire, Printemps, ce genre de choses.
    InformationsquelleAutor M. Jessup
  2. 11

    La meilleure Pratique est d'avoir un cas de test par la méthode. Le nom de la méthode décrit le test que vous effectuez. Il est plus facile de débogage lors de votre test échoue quand il est juste un faire valoir.

    • je pense que "la Meilleure Pratique est d'avoir un cas de test par la méthode" doit être "la Meilleure Pratique est d'avoir un assert par cas de test".
    InformationsquelleAutor RMT
  3. 11

    Divide et impera 🙂 donc divisée en plusieurs petites affaires ...plus facile à corriger en cas d'erreurs.

    InformationsquelleAutor Cris
  4. 2

    Vous confondez un test avec un affirmation. Votre méthode de test avec plusieurs asserts teste plusieurs choses: réglage par défaut et paramètre une variable de contexte. Mais une méthode de test qui teste une chose peut également avoir plusieurs asserts.

    Un bon modèle à utiliser pour chaque test de quatre phases:

    1. Installation: lorsque vous créez les objets dont vous avez besoin pour effectuer le test, et si nécessaire de modifier ces objets pour les mettre dans les états initiaux.
    2. Exercice: lorsque vous effectuez l'opération que vous souhaitez tester. Ce sera un appel de méthode, ou un appel de constructeur.
    3. Vérifier: lorsque vous vérifiez que les objets soumis à l'essai sont dans l'état correct(s), et de vérifier la valeur retournée par la méthode de l'appel dans la exercice phase, si elle a retourné une valeur. C'est l'endroit où vous placez votre asserts. Si vous utilisez ce modèle, il n'y a rien de mal avec le placement de plusieurs asserts dans le vérifier phase.
    4. Démontage: où vous détruire ou de fermer les objets que vous avez utilisé pour effectuer le test.

    C'est l'approche recommandée dans le livre xUnit des Modèles de Test: Refactoring de Code de Test par Gérard Meszaros.

    Revanche ce modèle avec ce que vous avez dans votre premier exemple, dans lesquelles il semble que vous feriez cela:

    1. Configuration initiale
    2. Exercice constructeur
    3. Vérifier par défaut
    4. Exercice pour définir une variable de contexte
    5. Vérifiez le paramétrage de la variable de contexte
    6. Démontage
    InformationsquelleAutor Raedwald
  5. 0

    Eclipse génère de l'unité de test par la méthode qui semble être une approche raisonnable.
    Si la méthode éprouvée est trop complexe pour un test à l'aide d'une méthode de test alors Vous pouvez envisager de re affacturage elle.

    Mais beaucoup plus meilleure approche est d'utiliser TDD et écrire les tests initiaux qui va conduire le reste de la conception et de la mise en œuvre.

    Personnellement, je préfère avoir un test par la méthode avec la Couverture de Code pour Java pour Eclipse http://www.eclemma.org.

    L'outil vous indiquera ce que Vous avez fait les tests.

    InformationsquelleAutor Prem