Que signifie “DAMP not DRY” quand on parle de tests unitaires?
J'ai entendu quelqu'un dire que les tests unitaires (par exemple, nUnit, jUnit, xUnit) devraient être
(Les tests unitaires, par exemple, doivent contenir "code humide" et non "code sec")
De quoi parlent-ils?
C'est un équilibre, pas une contradiction
DAMP et DRY ne sont pas contradictoires, mais équilibrent deux aspects différents d'un code maintenabilité. Le code gérable (code facile à modifier) est l’objectif ultime.
DAMP (Phrases descriptives et significatives) favorise la lisibilité du code.
Pour maintenir le code, vous devez d’abord comprendre le code. Pour le comprendre, vous devez le lire. Considérez un instant combien de temps vous passez lecture code. C'est beaucoup. DAMP améliore la facilité de maintenance en réduisant le temps nécessaire à la lecture et à la compréhension du code.
DRY (Ne vous répétez pas) favorise la orthogonalité du code.
La suppression de la duplication garantit que chaque concept du système possède une seule représentation faisant autorité dans le code. Une modification apportée à un concept commercial unique entraîne une modification unique du code. DRY augmente la maintenabilité en isolant le changement (risque) uniquement des parties du système devant changer.
Alors, pourquoi la duplication est-elle plus acceptable dans les tests?
Les tests contiennent souvent une duplication inhérente, car ils testent la même chose encore et encore, uniquement avec des valeurs d'entrée ou un code de configuration légèrement différents. Cependant, contrairement au code de production, cette duplication n'est généralement isolée que dans les scénarios d'un seul appareil/fichier de test. De ce fait, la duplication est minimale et évidente, ce qui signifie que le projet présente moins de risques que les autres types de duplication.
En outre, la suppression de ce type de duplication réduit la lisibilité des tests. Les détails précédemment dupliqués dans chaque test sont maintenant cachés dans une nouvelle méthode ou classe. Pour obtenir une image complète du test, vous devez maintenant reconstituer mentalement toutes ces pièces.
Par conséquent, étant donné que la duplication du code de test comporte souvent moins de risques et favorise la lisibilité, il est facile de voir comment elle est considérée comme acceptable.
En principe, privilégiez DRY dans le code de production, favorisez DAMP dans le code de test. Bien que les deux soient également importants, avec un peu de sagesse, vous pouvez faire pencher la balance en votre faveur.
DAMP - Phrases descriptives et significatives.
"DAMP not DRY" valorise la lisibilité lors de la réutilisation du code. L'idée de DAMP not DRY dans les scénarios de test est que les tests doivent être faciles à comprendre, même si cela signifie que les scénarios de test ont parfois du code répété.
Voir aussi Le code en double est-il plus tolérable dans les tests unitaires? pour une discussion sur les avantages de ce point de vue.
Il a peut-être été inventé par Jay Fields , en relation avec les langages spécifiques à un domaine.
"DRY" est "Ne te répète pas"
C'est un terme utilisé pour dire aux gens d'écrire du code réutilisable, de sorte que vous ne finissiez pas par écrire un code similaire encore et encore.
"DAMP" est "Phrases descriptives et significatives".
Ce terme est destiné à vous dire d’écrire un code qui peut être facilement compris par quelqu'un qui le regarde. Si vous suivez ce principe, vous aurez des noms de variable et de fonction longs et descriptifs, etc.
Damp = 'Phrases descriptives et significatives' - vos tests unitaires doivent pouvoir être lus:
La lisibilité est plus importante que d'éviter le code redondant.
De l'article:
DAMP signifie "phrases descriptives et significatives" et est le contraire de DRY, pas dans le sens où il est dit "tout devrait ressembler à une corbeille et être impossible à lire", en ce sens que la lisibilité est plus importante que d'éviter les codes redondants.
Qu'est-ce que cela signifie et où l'utiliser?
DAMP s’applique généralement lors de l’écriture du code de test. Le code de test doit être très facile à comprendre au point qu'une certaine redondance est acceptable.
Il y a déjà plusieurs réponses ici, mais je voulais en ajouter une autre, car je ne pensais pas qu'ils l'expliquaient nécessairement aussi bien qu'ils le pourraient.
L'idée de DRY (ne vous répétez pas) est que, dans votre code application, vous voulez éviter le code redondant ou reptétif. Si vous avez quelque chose que votre code doit faire plusieurs fois, vous devriez avoir une fonction ou une classe pour cela, plutôt que de répéter le même code à plusieurs endroits.
C'est un concept de programmation assez bien connu.
DAMP (Phrases descriptives et moyennes) est destiné à vos tests unitaires. L'idée ici est que les noms de vos méthodes de tests unitaires doivent être longs et descriptifs, c'est-à-dire des phrases courtes décrivant ce que vous testez.
par exemple: testWhenIAddOneAndOneIShouldGetTwo() { .... }
Lorsque vous lisez un nom de méthode DAMP comme celui-ci, vous devez comprendre exactement ce que le testeur essayait de réaliser, sans même avoir à lire le code de test (bien que le code de test puisse également suivre ce concept également bien sûr avec des noms de variables verbeux, etc).
Cela est possible car une méthode de test unitaire ayant une entrée et une sortie attendues très spécifiques, le principe DAMP leur convient bien. Il est peu probable que les méthodes de votre code d’application principale soient suffisamment spécifiques pour justifier de tels noms, en particulier si vous l’avez écrite en gardant à l’esprit le principe DRY.
DAMP et DRY ne se contredisent pas - ils couvrent différents aspects de l'écriture de votre code - mais ils ne sont toutefois pas utilisés conjointement car les méthodes écrites avec le principe DRY à l'esprit serait polyvalent et ne conviendrait probablement pas pour un nom de méthode très spécifique. Par conséquent, en général, comme expliqué ci-dessus, le code de votre application doit être DRY et votre code de test unitaire DAMP.
J'espère que cela aide à l'expliquer un peu mieux.
DAMP signifie "phrases descriptives et significatives" et est le contraire de DRY, pas dans le sens où il est dit "tout devrait ressembler à une corbeille et être impossible à lire", en ce sens que la lisibilité est plus importante que d'éviter les codes redondants.
Je suis d'accord avec Chris Edwards sur le fait qu'il faut trouver un équilibre entre les deux. Une autre chose à noter est que si, en essayant de supprimer la duplication, vous finissez par ajouter beaucoup de structure supplémentaire dans le code de test de votre unité (par exemple, lorsque vous prenez DRY à l'extrême), vous courez le risque d'introduire bugs là-dedans. Dans une telle situation, vous devrez soit tester vos tests unitaires, soit laisser des fragments de structure non testés.
Je ne souhaite pas dupliquer les efforts ici, mais vous pouvez avoir des tests qui sont DAMP mais qui ont l'avantage de DRY. D'un autre côté, les tests DRY ne satisferont pas les tests DAMP dans certains cas.
J'ai blogué à propos de DRY _ vs DAMP, qui comprend quelques exemples.
Aucune de ces approches ne devrait être votre seule solution, parfois DAMP est excessif, d'autres fois un ajout très agréable.
En règle générale, vous devez appliquer la règle de trois. Si vous repérez une duplication une troisième fois, il peut être intéressant d’écrire des tests de style DAMP, mais même dans ce cas toute la duplication n’est pas mauvaise . Le contexte compte.