Tester la valeur par défaut et le setter dans le même scénario de test ou dans des scénarios de test séparés.

Question

Recommandez-vous de regrouper les cas de test dans des méthodes @Test ou d'avoir une méthode @Test par scénario de test ? Par exemple, supposons qu'il existe différentes façons de définir le contexte dans une application.

L'idée suivante est-elle acceptable ?

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

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

    ...
}

Ou bien, préférez-vous le faire comme ceci, en ayant chaque méthode aussi 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é.

Answer 1

Je préfère avoir un scénario de test par méthode.

Tout d'abord, il est plus facile de voir quels cas sont testés s'ils sont divisés en méthodes, plutôt que de chercher des commentaires intégrés dans le code. La plupart des IDEs vous donneront un résumé des méthodes, donc au lieu de dire "est-ce que j'ai testé le cas limite XYZ ?" et ensuite de chercher un commentaire, ou de chercher le code qui met en place ce cas limite, vous cherchez simplement la méthode appelée setupContextEdgeCaseXYZ() .

Une deuxième raison est que si vous avez plusieurs cas ensemble, l'un peut échouer et les autres ne s'exécutent jamais.

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

Avec cette structure, il serait plus facile de déterminer que la vérification des entrées est mauvaise et que le cas limite 2 est mal traité, mais que les autres sont corrects (et vous pourriez découvrir que deux cas défaillants sont liés et que le problème est diagnostiqué plus rapidement).

Une troisième raison est que vous pouvez accidentellement laisser des valeurs d'un ensemble de tests précédents qui invalident un dernier test de manière inaperçue. 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);
}

En séparant les cas, vous pouvez éviter des erreurs comme celles mentionnées ci-dessus, qui se transformeraient en une erreur de compilation ou un avertissement.

Answer 2

La meilleure pratique consiste à avoir un scénario de test par méthode. Le nom de la méthode décrit le test que vous effectuez. Il est plus facile de déboguer lorsque votre test échoue lorsqu'il n'y a qu'une seule assertion.

Answer 3

Divide et impera :) donc diviser en plusieurs petits cas ...plus facile à corriger en cas d'erreurs.

Answer 4

Vous confondez un test avec un assertion . Votre méthode de test avec plusieurs assert teste plusieurs choses : réglage par défaut y définir une variable contextuelle . Mais une méthode de test qui teste une chose peut aussi avoir de multiples assert s.

Un bon modèle à utiliser est que chaque scénario de test comporte quatre phases :

1. Configuration où vous créez les objets dont vous avez besoin pour effectuer le test et, si nécessaire, modifiez ces objets pour les placer dans les états initiaux requis.
2. Exercice : où vous effectuez l'opération que vous testez. Il s'agira d'un appel de méthode, ou d'un appel de constructeur.
3. Vérifier où l'on vérifie que les objets testés sont dans le(s) bon(s) état(s), et où l'on vérifie la valeur renvoyée par la méthode que l'on a appelée dans l'étape 1. exercice s'il a retourné une valeur. C'est ici que vous placez votre assert s. Si vous utilisez ce modèle, il n'y a rien de mal à placer de multiples assert dans le vérifier phase.
4. Démontage : où vous détruisez ou fermez les objets que vous avez utilisés pour effectuer le test.

C'est l'approche recommandée dans le livre xUnit Test Patterns : Refactorisation du code de test par Gerard Meszaros.

Comparez ce schéma avec celui de votre premier exemple, dans lequel il semble que vous feriez ceci :

1. Configuration initiale
2. Constructeur d'exercice
3. Vérifier la valeur par défaut
4. Exercice pour définir une variable contextuelle
5. Vérifier le paramétrage de la variable contextuelle
6. Démontage

Answer 5

Eclipse génère des tests unitaires par méthode, ce qui semble être une approche raisonnable. Si la méthode testée est trop complexe pour être testée à l'aide d'une seule méthode de test, vous pouvez envisager de la réévaluer.

Mais une approche bien plus efficace consiste à utiliser la méthode TDD et à écrire les tests dès le départ, ce qui déterminera le reste de la conception et de la mise en œuvre.

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

L'outil vous indiquera ce que vous êtes en train de tester.