Quelle doit être la taille de mon projet pour que je puisse le tester? [fermé]


86

Je suppose que mon projet est suffisamment découplé pour permettre les tests unitaires. Mais quelle doit être la taille de mon projet pour que les tests unitaires en valent la peine?

Nous faisons tous des erreurs et personne n'est parfait, mais je me considère comme un bon programmeur capable de gérer les erreurs de petits projets. Ou bien les tests unitaires sont-ils une nécessité absolue, quelle que soit la taille de votre projet?


26
La grande hypothèse erronée que vous faites est que le projet n’est que pour vous et qu’il ne l’est que pour le moment . Et si vous le laissez quelques mois, faites autre chose, puis revenez-y? Aurez-vous la même confiance pour être un "programmeur décent" (ce qui n'a rien à voir avec le fait de tester ou non)? Et si quelqu'un d'autre prend en charge votre projet ...? Un grand blogueur (qui n’est malheureusement plus actif) a écrit que vous devriez toujours "prendre en charge le lecteur de code, pas le rédacteur de code".
Amos M. Carpenter

6
Que diriez-vous de cela (destiné à C # .NET): int x = 3 * (1/3); Quelle est la valeur stockée dans x une fois l'opération terminée? Mon argument est que même le code à une ligne peut nécessiter des tests car il pourrait conduire à un bogue, soit parce que vous ne savez pas, soit parce que vous savez, mais vous avez fait le mauvais code.
NoChance

2
@aaamos, je pense que vous manquez mon point. Le fait que cette question soit posée à elle seule montre que j’envisage également de prendre en charge le lecteur de code.
Lamin Sanneh

13
Ayant fait le travail dans les deux sens, je peux vous dire qu'il est tellement plus facile d'écrire les tests au fur et à mesure que vous avancez (c.-à-d. Lorsque le projet est petit) que de revenir en arrière et d'écrire des tests unitaires plus tard, lorsque vous estimez que le projet a rencontré des difficultés arbitraires. " nous devrions écrire des tests maintenant "condition.
Wonko the Sane

1
Vous posez la mauvaise question. Peu importe la taille du projet. La question est de savoir à quel point cela vous importe si c'est correct. Si l'exactitude est importante, les tests unitaires sont un moyen efficace d'améliorer l'exactitude.
Mark E. Haase

Réponses:


206

Votre projet est déjà assez grand.

D'après mon expérience, une classe et une fonction ont été suffisantes pour prendre en compte le besoin de tests unitaires.

    class Simple {
        boolean reallySimple() {
            return true; // how do we make sure it doesn't change to false?
        }
    }


    class SimpleTest {
        void assertReallySimple() {
            // ensure reallySimple return value isn't changed unexpectedly
            UnitTestFramework.assertTrue(new Simple().reallySimple());
        }
    }

24
Vous devriez sûrement commencer plus tôt, au point de classe 0/0 ... si vous suivez TDD :)
Kaz Dragon

115
+1 Si votre programme est assez gros pour avoir des bugs, il est assez grand pour avoir des tests unitaires.
Jason Orendorff

9
@JasonOrendorff: Je me moque de cela pour en faire une affiche et je la place dans mon bureau. Brillant.
Justin ᚅᚔᚈᚄᚒᚔ

De plus, cela permet une refactorisation "en toute sécurité".
Timo

7
Bien que je ne sois pas nécessairement en désaccord avec le sentiment, si votre code est vraiment aussi simple, vous pouvez sans doute vous en tirer avec de simples assertions au lieu de tests unitaires complets.
Chuu

109

Je n'ai jamais souscrit à l'idée de "vous devez tout tester", bien qu'il y ait certainement des gens qui en ont (voir la réponse de gnat !).

En ce qui me concerne, les principaux avantages des tests unitaires sont les suivants:

  1. Faire en sorte que les changements ne cassent pas les choses.
  2. Vous aider à concevoir des interfaces sensibles pour vos classes (car cela vous oblige à être un client de votre propre code).
  3. Document d'aide sur la manière dont votre code devrait être utilisé.

Fondamentalement, vous devez peser le temps qu'il vous faudra pour écrire et gérer des tests par rapport à ces facteurs.

Le numéro 1 suffit généralement pour que cela vaille la peine de passer des tests. D'après mon expérience, plus de 95% du code sera modifié tôt ou tard.


8
Convenez de ceci: lorsque vous travaillez dans un seul atelier de développement, vous devez trouver un équilibre entre la qualité du logiciel et tout tester (ce qui peut prendre beaucoup de temps). Ne pas oublier que chaque fois que vous faites un changement , vous devrez peut - être modifier vos tests unitaires pour costume
Matt Wilko

1
Vous ne devriez pas tout tester, mais tout comportement exposé au monde extérieur. Il y a certainement des coûts de maintenance liés aux tests, et comme Kent Beck l'a indiqué dans une réponse à SO (je pense que c'était SO): testez suffisamment pour vous assurer que votre code est correct.
Wayne Werner

10
J'ajouterais que si vous ne faites que des tests automatisés minimes, les tests unitaires ne sont pas à la hauteur. Optez plutôt pour des tests d'intégration / de fumée de haut niveau qui transmettent bout à bout quelques ensembles de données sans vous moquer de rien. Vous voulez que ces tests utilisent autant que possible votre base de code et couvrent tous les cas d'utilisation et chemins d'exécution normaux. Une chance de 75% de savoir que vos modifications ont cassé quelque chose, quelque part, dans l'application est plus bénéfique que de 5% de chance de savoir que vous avez cassé SomeClass.OneOfTheHandfulOfTestedFunctions ().
Dan Neely

3
Euh, je pense que vous en avez manqué un: "Assurez-vous que le code fonctionne comme prévu!"
BlueRaja - Danny Pflughoeft

3
@ BlueRaja-DannyPflughoeft: En fait, il serait plus précis de dire: "Assurez-vous que le code réussit les tests unitaires que vous avez écrits!"
vaughandroid

34

C'est simple: vous n'avez pas besoin de tests unitaires si vous voulez supprimer le programme après l'avoir exécuté une fois.

Si cela vous semble excessif, réfléchissez à ce que l’alternative signifierait. S'il y avait une taille en dessous de laquelle les tests unitaires ne rapportent pas, vous devriez continuer à juger: "Ai-je déjà atteint la taille magique? Devrais-je commencer à écrire des tests?" Maintenant, les programmeurs sont notoirement mauvais pour prédire l'avenir et ils sont notoirement mauvais pour juger de leurs propres compétences. Un code qui vous paraît clair comme du cristal deviendra incompréhensible, même si vous attendiez un mois. Un projet que vous êtes absolument, positivement certains ne sera jamais utilisé à nouveau, et que vous gardiez autour simplement sur la chance à distance que vous voudrez peut - être chercher comment vous avez résolu quelque chose avant, ne sera demandé à nouveau, et vous recevrez des demandes de modification.

Il est donc très probable que vous pensiez mal si le test est utile ou non, et lorsque vous commencez à avoir besoin de tests, vous n'êtes déjà pas sûr à 100% de la sémantique exacte à tester. Étant donné que je pense que tous les programmes, à l'exception des programmes uniques triviaux, tirent parti des tests unitaires, je considère que le coût des efforts consacrés à des tests qui ne sont jamais répétés est négligeable par rapport aux risques d'extension d'un code non testé et mal compris.


22
Les programmeurs sont notoirement mauvais pour juger de leur propre capacité à prédire l'avenir
superM

3
@superM Je suis d'accord avec toi. Le programme "Courez une fois et jetez" que j'ai déjà écrit au cours de ma courte carrière est resté, a été exécuté tous les quelques jours et est devenu critique. J'appelle ça le "temporarmanent" c'est à dire l'effet temporaire-permanent ... soupir
Jalayn

@Jalayn La réponse n'est-elle pas simplement qu'il faut revenir en arrière et ajouter des tests unitaires dès que cette réalisation survient?
Cornel Masson

@CornelMasson Vous avez absolument raison, attendez-vous à ce qu'il soit souvent difficile de convaincre les gestionnaires que "ce n'est pas encore fini", car les tests manquent :-)
Jalayn

@Jalayn: Trop vrai!
Cornel Masson

22

Il y a quelque temps, j'ai trouvé un article intéressant: Pourquoi les tests unitaires accélèrent le développement . Cela peut vous aider à répondre à la question.

... Et si la base de code ... était dotée d'un ensemble substantiel de tests unitaires. Un ensemble qui dirait: «si tous les tests réussissent, je garantis que le code fait toujours ce qu'il devrait faire» et si un test échoue, il vous indique exactement où un comportement est rompu. C’est génial, je pourrais changer le code pour ajouter les choses que je veux sans errer si le code fait toujours ce qu’il devrait faire, je viens de lancer les ... tests et j’ai confiance. En tant qu’ingénieur logiciel, c’est un monde formidable. J'ai remarqué que je pouvais avancer beaucoup plus vite ...

J'ai la Foi".

C'est probablement la raison la plus importante pour laquelle les tests unitaires accélèrent le développement dans un contexte d'entreprise.

Je peux avoir confiance que tout fonctionne encore si tous les tests réussissent. Si les tests échouent, ils indiqueront exactement où se situe le problème ...

... vous devez avoir une couverture de tests unitaires élevée et de bons tests unitaires . Lorsque ces conditions sont respectées, vous vous retrouvez dans une situation où l'effort pour ajouter de nouvelles fonctionnalités est presque indépendant de la taille de l'application et qui, à long terme , accélérera le développement .

Michael Feathers a introduit dans l'un de ses livres deux façons de travailler avec des changements de code:

  • éditer et prier,
  • couvrir et modifier.

Peu importe la taille de la base de code.


18

Selon Kent Beck, dans sa réponse à la question Stack Overflow, quelle est la profondeur de vos tests unitaires? , vous devriez tester le code que vous avez tendance à vous tromper.

Si je ne commets généralement pas un type d'erreur (par exemple, définir les mauvaises variables dans un constructeur), je ne le teste pas.


4
Bon point, et cela implique que la question du PO est fausse; si le test n'a rien à voir avec la taille du projet. Une base de code à 5 lignes peut nécessiter des tests, et une méthode à une ligne dans une base de code volumineuse peut ne pas en être ainsi (bien que d'autres éléments de cette base de code le fassent).
Nathan Long

Cela peut fonctionner pour de petits projets sur lesquels vous travaillez seul, mais pour un projet qui est fait pour le travail (où vous ne contrôlez pas qui travaillera dessus) ou pour tout ce qui peut être open source, vous avez besoin tout tester. Et vous devez commencer immédiatement car plus tard, il sera "trop ​​difficile de remplacer tout le code déjà écrit"
xaxxon

@xaxxon: Kent parle en fait de cela dans la même réponse que celle de Mansuro: "Lors du codage sur une équipe, je modifie ma stratégie pour tester soigneusement le code que nous avons collectivement tendance à nous tromper."
Henko

Non, c'est toujours incroyablement myope. Vous ne pouvez pas savoir qui travaillera sur le code dans le futur. C'est le type de mentalité qui afflige les développeurs juniors.
xaxxon

5

Les tests unitaires sont implémentés pour gagner du temps et améliorer:

  • suivi des bogues
  • refactoring et / ou ré-écriture de code
  • test d'intégration
  • tests de régression, etc.

Il est indispensable d’écrire des tests unitaires pour des parties relativement complexes du programme.

Si vous êtes certain que l'écriture de tests unitaires maintenant ne vous fera pas gagner du temps, vous pouvez le sauter. Cependant, on ne sait jamais, et personnellement, je ne peux pas penser à un cas où il est moins coûteux (en termes de temps, d'argent et de nerfs) de ne pas écrire les tests unitaires, mais de faire tous les tests manuellement.


Généralement une bonne réponse, donc +1. Cependant, je pense que votre dernier point passe à côté du fait que vous voudrez toujours / devrez tester manuellement vos tests unitaires!
Vaughandroid

@Baqueta, je n'avais peut-être pas l'air clair, mais je ne voulais pas dire que les tests unitaires remplacent complètement les tests manuels
superM

4

"Dois-je tester l'unité", on peut généralement y répondre en répondant à la question suivante: "Est-il important que cette fonction fonctionne correctement, et est-il important pour moi de savoir quand elle cesse de fonctionner?"

Bien sûr, c'est beaucoup plus compliqué que cela, mais c'est une bonne façon de commencer. Finalement, vous déterminerez également si le code est déjà testé en raison de son utilisation dans une autre fonction, ou si votre temps serait mieux dépensé dans une autre fonction, etc.


4

À moins que vous n'écriviez du code sans le tester, vous devrez toujours supporter le coût des tests.

La différence entre avoir des tests unitaires et ne pas les avoir est la différence entre le coût de la rédaction du test et son coût d'exécution par rapport au coût du test manuel.

Si le coût de l'écriture d'un test unitaire est de 2 minutes et que le coût de l'exécution du test unitaire est pratiquement égal à 0, mais que le coût du test manuel du code est de 1 minute, vous arrêtez même si vous avez exécuté le test deux fois.


Pendant de nombreuses années, j'ai eu la fausse impression que je n'avais pas assez de temps pour écrire des tests unitaires pour mon code. Lorsque j’écrivais des tests, ils étaient gonflés et constituaient des choses lourdes qui ne m’avaient incité à penser que je ne devrais écrire des tests unitaires que lorsque je savais que c’était nécessaire.

Récemment, on m'a encouragé à utiliser Test Driven Development et j'ai trouvé qu'il s'agissait d'une révélation complète. Je suis maintenant fermement convaincu que je n'ai pas le temps de ne pas écrire de tests unitaires .

D'après mon expérience, en développant en gardant à l'esprit les tests, vous obtenez des interfaces plus propres, des classes et des modules plus ciblés et généralement plus de code SOLID testable.

Chaque fois que je travaille avec du code existant qui ne comporte pas de tests unitaires et que je dois tester manuellement quelque chose, je continue de penser "cela serait tellement plus rapide si ce code comportait déjà des tests unitaires". Chaque fois que je dois essayer d'ajouter une fonctionnalité de test unitaire au code avec un couplage élevé, je continue de penser "cela serait tellement plus facile si cela avait été écrit de manière découplée".


Version TL; DR :

Rédigez un test lorsque le coût de la rédaction du test, plus le coût de son exécution autant de fois que nécessaire, risque d'être inférieur au coût de son test manuel autant de fois que nécessaire.

Rappelez-vous cependant que si vous utilisez TDD, le coût de la rédaction des tests diminuera probablement à mesure que vous vous améliorerez, et à moins que le code ne soit absolument trivial, vous finirez probablement par exécuter vos tests plus souvent que prévu.


3

Testez dès que vous observez des régressions ou craignez d’en causer avec vos modifications sans vous en rendre compte.

Allumez cette peur, laissez-la atteindre une taille adéquate: plus vous testez tôt, mieux c'est.

Remarque: en fonction de votre rôle dans le projet, les tests unitaires peuvent ne pas être le seul type de tests que vous souhaitez écrire.

Tout le monde est légitimement obsédé par les tests unitaires , à cause des mauvaises pratiques de test traditionnelles dans le passé; mais si vous n'avez jamais testé auparavant, vous devriez vraiment vous concentrer sur les tests en général , les tests unitaires ne vont pas à eux seuls résoudre les problèmes du monde.


1
Je vois que vous pointez, mais que votre unité n’est pas en train de tester le point de départ des programmeurs de démarrage. Et aussi, pourriez-vous préciser ce que vous entendez par "tester en général". Merci.
Lamin Sanneh

1
Il existe au moins deux autres types de tests: les tests d'intégration et les tests d'acceptation. Les tests unitaires couvrent une unité spécifique (par exemple, cette fonction de cette classe est supposée masquer le fizz). Vous moquez / stubez tous les autres endroits où cette classe interagit, en lui transmettant el fake-o data. Lorsque vous effectuez des tests d’intégration, vous combinez deux classes (ou plus) pour vous assurer que vos cours se déroulent comme vous le souhaitez. Finalement, vous créez suffisamment de tests pour effectuer des tests de bout en bout de tout votre système, parfois appelés "tests de détection de la fumée".
Wayne Werner

Il existe également des tests de régression tout court. Les tests de régression sont généralement plus volumineux que les tests unitaires, peuvent prendre une journée, peuvent impliquer l’accès à des données de test et à des environnements de test spéciaux. En réalité, les tests unitaires sont une version plus petite, plus élégante et plus facile à gérer des tests de régression (à l’ancienne).
ZJR

1

Je crois que ce n'est pas la taille du projet mais le type de projet qui décide s'il doit utiliser des tests ou non.

Si vous travaillez sur une preuve de concept ou sur un autre projet dont l'objectif est de tirer des leçons du codage, les tests ne sont pas nécessaires. Si le projet est destiné à être utilisé, peut-être même envoyé en production, alors il devrait être testé.

Une citation de "Clean Code" de Robert C. Martin : "S'il est trivial d'écrire, c'est trivial de tester", il n'y a donc aucune excuse pour ignorer les tests pour les programmes courts et triviaux.


0

Ce n'est vraiment pas une question de taille - c'est ce que vous en faites (et quel âge il a). Si j'essaie de comprendre le fonctionnement d'une technologie et que je prévois de le jeter (nous appelons cela une pointe dans Scrum), je vais simplement coder sans faire beaucoup de tests. Si vous avez l’intention de le développer plus avant (même si vous ne faites que vous amuser), vous devez écrire des tests autour du code. La TDD est une technique de conception avant même d’être une technique d’essai. Vous voulez avoir une image claire de ce que vous voulez que le code fasse avant de vous lier aux détails de l'exécution. Je voudrais aussi pasrecommande d'essayer d'écrire des tests unitaires approfondis autour de grandes quantités de code hérité. Essayez d’identifier les parties complexes (qui ont une grande complexité cyclomatique / sens du code spaghetti) et les parties qui échouent fréquemment (elles seront souvent les mêmes). Comme d'autres l'ont suggéré, j'irais lire le livre de Kent Beck sur le TDD et définitivement le livre de Michael Feather. Ce qu’ils ne couvrent pas beaucoup, c’est l’ aspect politique de la rédaction de tests unitaires autour du code. Beaucoup de développeurs détestent devoir modifier leur code pour le rendre testable, et beaucoup ne ressentent pas le besoin de tester du code. C'est un travail sur lequel nous devons travailler. Toutes les autres disciplines du génie doivent prouver (souvent mathématiquement) que leurs travaux respectaient les spécifications. Nous devrions faire la même chose.


-1

Lier un projet à des limites de classes ou de fonctionnalités, puis juger si cela convient aux tests unitaires peut être erroné. Les tests unitaires d'une application présentent de nombreux avantages, mais la vraie beauté commence lorsque vous devez gérer une application ou travailler dans un environnement distribué. Donc, le choix vient ici. Même un petit changement dans votre code peut provoquer des catastrophes.
Je ne suggérerais pas seulement «Test unitaire», mais recommanderais également de vérifier la couverture de votre code, en veillant à ce que le maximum de votre code soit couvert par le test unitaire. Le seuil de couverture de code ne doit pas être inférieur à 95% et la cible doit être proche de 100% . Vous pouvez utiliser des outils pour suivre votre couverture de code et générer un rapport.
Visual Studio fournit des données de couverture -http://msdn.microsoft.com/en-us/library/ms182496(v=80s.aspx
. Vous pouvez également utiliser NCover ou dotCover.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.