C'est une mauvaise pratique d'avoir plus d'une affirmation dans un test unitaire?

Parfois, j'ai exactement un assert par cas de test, mais je pense que le plus souvent j'ai plusieurs assert consolidés.

J'ai vu le cas que @Arkain échappe, où un très grand morceau de code a une seule unité de la suite de tests avec juste un peu de cas de test, et ils sont tous étiquetés testCase1, testCase2, etc, et chaque cas de test a des centaines de affirme. Et encore mieux, chaque état dépend habituellement de la les effets secondaires de l'exécution précédente. Chaque fois que l'échec de la construction, toujours dans un test unitaire, il faut un certain temps pour déterminer où était le problème.

Mais l'autre extrême, est ce que votre question suggère: un autre cas de test pour chaque état possible. En fonction de ce que vous faites des tests, cela peut avoir du sens, mais souvent j'ai plusieurs asserts par cas de test.

Par exemple, si vous avez écrit java.lang.Integer, vous pourriez avoir quelques cas qui ressemblent à:

public void testValueOf() {
    assertEquals(1, Integer.valueOf("1").intValue());
    assertEquals(0, Integer.valueOf("0").intValue());
    assertEquals(-1, Integer.valueOf("-1").intValue());
    assertEquals(Integer.MAX_VALUE, Integer.valueOf("2147483647").intValue());
    assertEquals(Integer.MIN_VALUE, Integer.valueOf("-2147483648").intValue());
    ....
}

public void testValueOfRange() {
    assertNumberFormatException("2147483648");
    assertNumberFormatException("-2147483649");
    ...
}

public void testValueOfNotNumbers() {
    assertNumberFormatException("");
    assertNumberFormatException("notanumber");
    ...
}
private void assertNumberFormatException(String numstr) {
    try {
        int number = Integer.valueOf(numstr).intValue();
        fail("Expected NumberFormatException for string \"" + numstr +
             "\" but instead got the number " + number);
    } catch(NumberFormatException e) {
        //expected exception
    }
}

Quelques règles simples que je peux penser de la main pour combien d'affirmer est à mettre dans un cas de test:

• Ne pas avoir plus d'un assert qui dépend de la les effets secondaires de l'exécution précédente.
• Groupe asserts en même temps que le test de la même fonction/caractéristique ou une facette de celle-ci--pas besoin de la surcharge de plusieurs scénarios de test unitaire lorsqu'il n'est pas nécessaire.
• Une des règles ci-dessus devrait être remplacé par le pragmatisme et le bon sens. Vous ne voulez probablement pas un millier de scénarios de test unitaire avec une seule affirmer dans chaque (ou même plusieurs affirme, et vous ne voulez pas un seul cas de test avec des centaines de assert consolidés.

Vos tests unitaires devraient être assez fines. En général, moins il l'affirme, le plus probable que votre test est de cibler une fonction spécifique, et ne pas se mélanger les tests pour plusieurs entités d'un même test. Est-ce à dire que tous les tests ne devrait avoir qu'un faire valoir? Non, mais je le considère comme un "test de l'odorat" si j'ai trouvé plusieurs affirme, potentiellement test de plusieurs choses dans la même unité de test. Traiter cette "odeur" comme une odeur de code et de refactoriser le test de l'améliorer afin qu'il ne teste que sur une "chose", même si cela nécessite plus qu'un faire valoir.

Par exemple, je suis en train de faire un projet MVC maintenant et l'un des tests que j'écris, c'est que la vue correcte est rendu par l'action. Il y aura peut-être plusieurs de ces si différents chemins de code peut entraîner différents points de vue. C'est la définition de la vue correcte: le résultat est le bon type et le nom correct. Cela nécessite deux affirme, mais je ne fais que des tests d'une chose.

var result = controller.Action() as ViewResult;

Assert.IsNotNull( result );
Assert.AreEqual( viewName, result.ViewName );

Je pourrais faire quelque chose de similaire avec le modèle, mais je ne voudrais pas tester que le modèle est correct dans le même test que la vérification de la vue, car ce sont les différents aspects du comportement du code. J'ai pu modifier le modèle ou la vue et en le mettant dans un autre test, seuls les tests concerné par cette caractéristique de la méthode doivent être modifiées.

Je ne la considérons pas comme une mauvaise pratique. Les tests unitaires peuvent faire ce qu'ils veulent: affirmer, journal de fichiers, envoyer des insultes par SMS à la gestion, à quoi que ce soit.

La possible problème est que la complexité peut changer le comportement du programme sous test, mais c'est rarement le cas si vous êtes prudent, et peuvent être découverts de toute façon.

Je dois certainement utiliser une seule affirmer dans la méthode d'essai! À l'aide de nombreuses assertions peuvent être l'odeur de code que vous souhaitez tester plus d'une chose. En outre, il ya une chance que quelqu'un peut ajouter de nouveaux affirmer dans votre test, au lieu d'écrire un autre. Et comment pouvez-vous comprendre comment vos autres affirme terminé lorsque la première a échoué?

Vous pouvez également trouvé intéressant cet article: https://timetocode.wordpress.com/2016/06/01/zen-of-unit-testing/

Un "test Unitaire" devrait test 1 unité, pour être aussi petite que possible et de tester seulement 1 chose certaine.
Je suggère d'avoir seulement 1 affirmer

MAIS je pense que c'est ok d'avoir 2 affirmations aussi longtemps qu'ils ne sont pas l'un derrière l'autre.

Mauvais exemple

public void ValidateRulesEntry_Valid_ValidConditionsFromFile()
{
    string condition = "Target.HasValue";
    string returnMessage;

    bool successFul = CodeParserTryParseCondition(condition, out returnMessage);


    Assert.IsTrue(successFul);
    Assert.IsFalse(string.IsNullOrEmpty(returnMessage));
    Assert.IsTrue(returnMessage == "OK");

}