Qu'est-ce qu'un rapport «lignes de code fonctionnelles» / «lignes de code de test» normales?

27

Je suis assez nouveau dans l'approche TDD et mes premières expériences disent qu'écrire 1 ligne de code fonctionnel signifie écrire environ 2-3 lignes de code de test. Donc, au cas où je vais écrire 1000 LOC, la base de code entière, y compris les tests, sera quelque chose comme ~ 3500 LOC.

Est-ce considéré comme normal? Quel est le ratio dans le code que vous écrivez?

— Andrey Agibalov
source

8

Oui, TDD est livré avec une étiquette coûteuse!

— EL Yusubov

6

votre nombre 2-3X est au mieux conservateur , il est en fait plus proche de 4-5X pour des choses comme C # / Java, Python / Ruby pourrait être plus proche de 2-3X, avec quelque chose de laconique comme Erlang étant plus proche de 1: 1. Cela dépend de la façon dont vous êtes dogmatique à propos du TDD, plus vous êtes dogmatique, plus ces ratios augmentent!

6

@tomwrong: Dans le livre de Kent, il cite Ward que vous devez passer des tests jusqu'à ce que votre peur se transforme en ennui.

— herby

4

@ElYusubov: Je ne suis pas du tout d'accord pour dire que c'est "cher". Il semble que ce soit le cas pour ceux qui comptent encore beaucoup de travail dans les COL. Mais le prix n'est pas en LOC, c'est en argent et en time-to-market. Et là, TDD n'est pas plus cher que tout autre processus de développement raisonnable.

— herby

5

Les gars, pourquoi commentez-vous au lieu de poster des réponses? Ce que vous écrivez a du sens.

— Andrey Agibalov

18

1: 3 est normal avec TDD.

D'après mon expérience, et aussi d'autres citations dont je me souviens.

— herby
source

12

... quelles citations?

— TehShrike

... me souviens vaguement ... Je ne me souviens pas déjà où c'était (peut-être dans le TDD de Kent Beck par exemple, peut-être quelque part dans c2.com). Je me souviens du sens, cependant, que trois fois plus de code de test que le code de production est correct.

— herby

Wow, exactement la même chose dans mon expérience aussi. (Je regarde les résultats de cloc en ce moment et j'ai recherché sur Google pour trouver des messages sur ce ratio)

— Nikolay Tsenkov

9

Il existe des variantes basées sur différents styles de codage et langues. Cependant, quelle que soit la langue que vous utilisez, la plus grande variation est vous.

Robert Martin a dit un jour:

«À mesure que les tests deviennent plus spécifiques, le code devient plus générique.»

Cela m'a fait réfléchir. Des tests plus spécifiques signifient plus de code de test. Un code de production plus générique signifie moins de code, donc les ratios test / code devraient augmenter à mesure que le code évolue.

Mais attendez, ce n'est pas bon non plus. Dans certains cas particuliers, par exemple lorsque vous définissez un certain algorithme, vous pouvez avoir seulement 6-10 lignes de code contenant quelques "si", un moment et peut-être 2-3 récursions. Je peux vous dire que ce code aura probablement plus de 100 lignes de code de test.

Dans un vrai projet, quelque chose de plus grand que quelques algorithmes, le rapport test / code devrait être compris entre 1: 1 et 2: 1. Si elle dépasse 2: 1, c'est une odeur que vous avez des tests qui devraient être refactorisés ou supprimés (ou peut-être du code difficile à tester). Vous devez toujours investir la même quantité de soins et de refactorisation dans vos tests que dans votre code de production.

Quoi qu'il en soit, la meilleure réponse à votre question est peut-être "Complexité cyclomatique" . Plus la complexité cyclomatique de votre méthode est élevée, plus vous devez écrire de manière exponentielle pour qu'elle couvre tous les cas.

— Patkos Csaba
source

3

Le ratio va varier en fonction de la taille de vos méthodes. La taille de vos méthodes variera selon le style de programmation, le langage et le domaine problématique.

Si vos méthodes sont courtes, 3: 1 est raisonnable. Si vos méthodes sont longues, alors 3: 1 est sur le côté haut.

Donc, pour répondre à votre question, cela dépend. :-)

— Jon Strayer
source

Cela dépend de ce que vous entendez par «les méthodes sont longues». Quelle image cela a créé dans ma tête, c'est que les méthodes sont inutiles longtemps, font trop de travail et ont trop de responsabilités (souvent avec trop de paramètres). Dans ce cas, une telle méthode nécessite proportionnellement plus de combinaisons pour couvrir les tests, donc je ne pense pas que le rapport changerait beaucoup ...

— herby

Supposons un instant que vous puissiez configurer un test, appeler la méthode à tester et vérifier le résultat en trois lignes de code. Si la méthode que vous testez est d'une ligne (comme cela se produit dans Scala), votre rapport de test à la production est de 3: 1. Si la méthode comporte six lignes, elle est de 1: 2. Six lignes, ce n'est pas si long.

— Jon Strayer

2

Pour les applications logicielles critiques, le ratio habituel est d'un jour de test pour 10 LoC fonctionnels.

Et cela ne compte pas TDD qui n'est pas une question de test mais de spécification.

— mouviciel
source

1

La taille de mon code de test est environ la moitié de ce que le code «réel» est global. Faire autrement indique que vos tests sont trop complexes et / ou votre code est trop difficile à tester et / ou votre code est trop dense / complexe.

Ou vous testez simplement trop et perdez votre temps sur des rendements décroissants.

Voir aussi "quand les tests unitaires sont-ils inappropriés ou inutiles?"

— Telastyn
source

-1

Mon ratio est d'environ 2-1 à 10-1 (code à tester). Assurez-vous que vos tests concernent la valeur / le comportement et non l'implémentation.

— Erez A. Korn
source