8
votes

Asser-ing-ing sur la méthode de la déchirure (@After) incorrecte?

J'ai plusieurs cas de test, même et si la logique est différente, la sortie doit être égale à toutes. Je pensais donc à les généraliser et à placer la méthode de l'affirmation une seule fois.

Y a-t-il quelque chose de mieux à le faire que celui-ci: P>

@Test
public void runTests() {
    Result result = JUnitCore.runClasses(Tests.class);
    assertThat(result.getRunCount(), is(2));
    assertThat(result.getFailureCount(), is(0));
}

java unit-testing junit

0 commentaires

3 Réponses :

5
votes

Si vous devez généraliser, vous pouvez créer une méthode comme xxx

et l'appeler à partir de toutes vos méthodes de test.

Si et quand un test échoue plus évident que le test a échoué.

0 commentaires

7
votes

Oui, affirmer dans la méthode de la déchirure est une mauvaise idée. Cette méthode existe, selon la documentation Junit,

Déplacez le luminaire, par exemple, fermez une connexion réseau. Cette méthode est appelée après l'exécution d'un test.
Je pense que le stockage de vos valeurs attendues et réelles dans la classe de test est une mauvaise idée en général. Ces variables dépendent du test, alors rangez-les dans votre cas de test et faites votre affirmation dans le boîtier de test. Par exemple: xxx
aussi, je vois dans votre code que tous les tests ont la même valeur attendue. C'est peut-être une bonne idée de varier vos tests afin que les valeurs renvoyées sont toujours différentes. Testez une seule valeur attendue tout le temps que le code fonctionne pour le résultat attendu. Essayez avec un peu plus, peut-être très différent et essayez de tester des cas d'angle.

6 commentaires

La classe que je teste est une sorte de classe de constructeur afin que je puisse construire ma sortie en utilisant différentes méthodes. Faire ces tests, je peux assurer que toutes mes méthodes fonctionnent et que la sortie est générée correctement. J'ai déjà détecté un bogue dans l'une de mes méthodes.

De plus, l'utilisation de statistiques dans votre test est une mauvaise idée.

@emory, vous voulez dire affirmer une variable statique ou utiliser des méthodes statiques ou les deux?

@Alexander: Dans ce cas, essayez d'autres méthodes avec d'autres valeurs qui généreront une sortie différente. Votre méthode peut fonctionner correctement pour une sortie donnée et être cassée pour un autre, de sorte que les tests différentes sont toujours une bonne idée, il élargit vos tests.

@Alexander si vous faites comme Vivien suggère alors cela ne sera pas un problème du tout. Si vous avez une variable escomptée statique, les tests ne sont pas vraiment indépendants les uns des autres.

J'ai convenu avec la déclaration selon laquelle les cas de test doivent être indépendants les uns des autres.

0
votes

Mon interprétation des réponses existantes est que vous ne devriez pas utiliser la déchirance des affirmations, par clarté:

Je suis d'accord avec Cette réponse qui affirme d'une méthode générale appelée explicitement de chaque méthode rendra plus claire quel test a échoué.
et je suis d'accord avec Cette réponse qui affirme en larmes va contre l'intention initiale de l'infrastructure de démolition. En utilisant Assert, cette voie rend l'intention de notre code moins clair.
Mais je pensais que cela valait la peine de mentionner explicitement ce qui aurait peut-être aussi été implicite dans cette réponse , ce qui est aussi En tant que confusion susceptible de provoquer une confusion, les affirmations en démolition peuvent réellement casser votre logique de test. Ceci est plus clairement démontré dans ce Réponse Python associée :

affirmer quelque chose dans votre démontage signifie que vous devez faire attention que tout le nettoyage est fait avant l'affirmation réelle sinon Le code de nettoyage peut ne pas être appelé si la déclaration d'assertion échoue et lève.

0 commentaires