Réutilisation de code dans les tests unitaires?

Question

Je continue d'entendre que les gens disent comment les tests doivent être simples, maintenables, simples, mais que se passe-t-il avec la réévaluation du code dans les tests unitaires?

Prenons par exemple:

def test_some_1():
    ...some code

def test_some_2():
    ...code repeated from test_some_1

ne serait-il pas préférable d'encapsuler le code répété des deux tests dans une fonction qui contient les assertions nécessaires?

J'ai discuté avec des programmeurs à ce sujet et ils sont en désaccord, ils ont déclaré que les tests devraient être stupides, cette réévaluation du code n'est pas bonne ici. La raison en est que cela n'est pas très clair dans la console Django où l'affirmation a réellement échoué, car l'affirmation était dans la fonction, bien que je ne suis pas d'accord parce que l'utiliser avec le nez vous donnerait le nom du test et la trace de la trace, bien que Les gars sont à nouveau désaccordés, indiquant qu'un test pouvait être invoqué individuellement sans nez (et donc vous ne pouviez donc pas voir tous ces détails).

Qu'est-ce que vous pensez?

• est-il bon d'utiliser la ré-utilisabilité du code dans des tests unitaires?
• Si la ré-utilisabilité peut / doit être utilisée, puis sur la manière de surmonter l'autre problème concernant la pointe des affirmations?

Answer 1

Les facteurs les plus importants pour la qualité du code, comme la clarté et la lisibilité, sont également importants pour le code de test.Si la répétition du code facilite la lecture, vous devez le faire, que ce soit du code de test que vous écrivez et vice versa.

Par exemple, dans un paquet que j'ai écrit, j'ai eu une fonction:

def _test_vector(self, a, b, c):
    # test the function with parameter values a, b, c
    # several asserts here to verify output of function tested

qui a permis d'écrire tous les vecteurs de test comme:

def test_vector1(self):
    self._test_vector(a=42, b=5, c="blah)

que, imo, améliore la clarté, car les tests individuels n'incluent que les informations spécifiques à ce test.

Les assertions d'identification doivent toujours être faciles.Même unittest vous donnera une trace de trace et si votre configuration de test ne pointe pas sur une affirmation particulière, vous aurez du mal à déboguer des défaillances de test et devriez certainement passer à quelque chose de sensible.

Answer 2

Comme vos pairs ont dit, vous devriez écrire vos tests muettes.Il y a plusieurs raisons à cela, le plus important est que vous souhaitez éviter une logique complexe dans les tests.Si vous écrivez vos tests "intelligents", ils ont tendance à contenir la même logique identique ou similaire que le code que vous essayez de tester.Cela signifie que vous risquez de faire la même erreur dans les deux endroits et de manquer des bugs que vous souhaitez trouver.

Une autre raison est que vous souhaitez que votre test agisse comme une documentation du code que vous essayez de tester.Si le test a un chemin d'exécution complexe à travers de nombreuses fonctions et logiques, il ne sera pas aussi facile à comprendre.Dans le meilleur des mondes, vous verriez comment le code de production est destiné à travailler simplement en ayant un coup d'œil au test.