Qu'est-ce que les tests unitaires ?

Question

J'ai vu de nombreuses questions demandant " comment " effectuer des tests unitaires dans un langage spécifique, mais aucune question demandant " quoi ", " pourquoi " et " quand ".

• Qu'est-ce que c'est ?
• Qu'est-ce qu'il fait pour moi ?
• Pourquoi devrais-je l'utiliser ?
• Quand dois-je l'utiliser (et aussi quand ne pas l'utiliser) ?
• Quels sont les pièges et les idées fausses les plus courants ?

Answer 1

Les tests unitaires consistent, en gros, à tester des parties de votre code de manière isolée avec du code de test. Les avantages immédiats qui viennent à l'esprit sont les suivants :

• L'exécution des tests devient automatisable et reproductible.
• Vous pouvez tester à un niveau beaucoup plus granulaire que les tests par pointer-cliquer via une interface graphique.

Notez que si votre code de test écrit dans un fichier, ouvre une connexion à une base de données ou fait quelque chose sur le réseau, il est plus approprié de le classer dans la catégorie des tests d'intégration. Les tests d'intégration sont une bonne chose, mais ne doivent pas être confondus avec les tests unitaires. Le code de test unitaire doit être court, facile et rapide à exécuter.

Une autre façon d'envisager les tests unitaires consiste à écrire les tests en premier. C'est ce qu'on appelle le développement piloté par les tests (TDD en abrégé). Le TDD apporte des avantages supplémentaires :

• Vous n'écrivez pas de code spéculatif "je pourrais avoir besoin de ceci dans le futur" - juste assez pour que les tests passent.
• Le code que vous avez écrit est toujours couvert par des tests.
• En écrivant le test en premier, vous êtes obligé de réfléchir à la façon dont vous voulez appeler le code, ce qui améliore généralement la conception du code à long terme.

Si vous ne faites pas de tests unitaires maintenant, je vous recommande de vous y mettre. Prenez un bon livre, pratiquement n'importe quel livre sur xUnit fera l'affaire car les concepts sont très transférables entre eux.

Parfois, l'écriture de tests unitaires peut être douloureuse. Lorsque cela se produit, essayez de trouver quelqu'un pour vous aider et résistez à la tentation d'"écrire simplement ce fichu code". Les tests unitaires sont un peu comme la vaisselle. Ce n'est pas toujours agréable, mais cela permet de garder votre cuisine métaphorique propre, et vous voulez vraiment qu'elle soit propre :)

---

Edit : Une idée fausse me vient à l'esprit, bien que je ne sois pas sûr qu'elle soit si courante. J'ai entendu un chef de projet dire que les tests unitaires obligeaient l'équipe à écrire tout le code deux fois. Si c'est ce que vous pensez, c'est que vous vous trompez. Non seulement l'écriture des tests accélère généralement le développement, mais elle vous donne aussi un indicateur pratique "maintenant j'ai fini" que vous n'auriez pas autrement.

Answer 2

Je ne suis pas en désaccord avec Dan (bien que le meilleur choix est peut être tout simplement de ne pas répondre)...mais...

Le test unitaire est le processus de l'écriture de code pour tester le comportement et la fonctionnalité de votre système.

Évidemment, les tests d'améliorer la qualité de votre code, mais ce n'est que superficielle bénéficier de tests unitaires. Le bénéfice réel sont à

1. De faciliter les changements de la technique mise en œuvre, tout en prenant soin de ne pas modifier le comportement (refactoring). Correctement l'unité de code à tester peut être remaniée de façon agressive/nettoyé avec un peu de chance de casser quoi que ce soit sans la remarquer.
2. Donner aux développeurs de confiance lors de l'ajout de comportement ou de faire des corrections.
3. Documenter votre code
4. Indiquer les zones de votre code qui sont étroitement couplés. Il est difficile de code de test unitaire qui est étroitement couplé
5. Fournir un moyen d'utiliser votre API et de regarder pour les difficultés de début
6. Indique les méthodes et les classes ne sont pas très cohérent

Vous devriez unité de test en raison de ses dans votre intérêt de fournir un maintenable et de la qualité du produit à votre client.

Je vous suggère de l'utiliser pour n'importe quel système ou d'une partie d'un système, dont les modèles de comportement réel. En d'autres termes, il est particulièrement bien adapté pour le développement de l'entreprise. Je ne voudrais pas l'utiliser pour jeter de l'utilité des programmes. Je ne voudrais pas l'utiliser pour les parties du système qui sont problématiques pour les tester (UI est un exemple courant, mais ce n'est pas toujours le cas)

Le plus grand écueil est que les développeurs de test trop grand d'une unité, ou qu'ils considèrent comme une méthode d'une unité. Cela est particulièrement vrai si vous ne comprenez pas l'Inversion de Contrôle - dans ce cas, votre appareil des tests de toujours se transformer en de bout en bout, les tests d'intégration. Test unitaire doit tester les comportements individuels - et la plupart des méthodes ont de nombreux comportements.

La plus grande idée fausse est que les programmeurs ne doit pas tester. Que de mauvaise ou paresseux programmeurs croient que. Si le gars de la construction de votre toiture ne pas le tester? Le médecin doit-il de remplacement d'une valve cardiaque de ne pas tester la nouvelle vanne? Seul un programmeur peut tester son code fait ce qu'il avait prévu qu'il fasse (AQ pouvez tester bord de cas - comment se comporte le code lorsque ses dit de faire les choses le programmeur n'a pas l'intention, et le client peut faire de test d'acceptation - le code de faire ce que ce que le client a payé pour le faire)

Answer 3

La principale différence des tests unitaires, par opposition à "ouvrir un nouveau projet et tester ce code spécifique", est qu'il s'agit de automatisé donc répétable .

Si vous testez votre code manuellement, cela peut vous convaincre que le code fonctionne parfaitement - dans son état actuel . Mais qu'en est-il une semaine plus tard, lorsque vous y avez apporté une légère modification ? Êtes-vous prêt à le tester à nouveau, à la main, chaque fois que tout ce qui est des changements dans votre code ? Très probablement pas :-(

Mais si vous pouvez exécuter vos tests à tout moment, d'un seul clic, exactement de la même manière, en quelques secondes puis ils sera vous montrent immédiatement quand quelque chose est cassé. Et si vous intégrez également les tests unitaires dans votre processus de construction automatisé, ils vous alerteront sur les bogues même dans les cas où une modification apparemment sans rapport a cassé quelque chose dans une partie éloignée de la base de code - quand il ne vous viendrait même pas à l'esprit qu'il est nécessaire de tester à nouveau cette fonctionnalité particulière.

C'est le principal avantage des tests unitaires par rapport aux tests manuels. Mais attendez, il y a plus :

• tests unitaires raccourcir la boucle de rétroaction du développement dramatiquement : avec un département de test séparé, il peut vous falloir des semaines pour savoir qu'il y a un bogue dans votre code, et à ce moment-là vous avez déjà oublié une grande partie du contexte, ce qui peut vous prendre des heures pour trouver et corriger le bogue ; en revanche, avec des tests unitaires, le cycle de retour d'information se mesure en secondes, et le processus de correction du bogue est généralement du type "oh merde, j'ai oublié de vérifier cette condition ici" :-)
• des tests unitaires efficaces document (votre compréhension) du comportement de votre code
• les tests unitaires vous obligent à réévaluer vos choix de conception, ce qui se traduit par un design plus simple et plus propre

Les cadres de tests unitaires, quant à eux, facilitent l'écriture et l'exécution de vos tests.

Answer 4

On ne m'a jamais enseigné les tests unitaires à l'université, et il m'a fallu un certain temps pour "comprendre". J'ai lu des articles à ce sujet, je me suis dit "Ah, oui, les tests automatisés, ça pourrait être cool je suppose", puis j'ai oublié.

Il m'a fallu un peu plus de temps avant de comprendre le but recherché : Disons que vous travaillez sur un gros système et que vous écrivez un petit module. Il se compile, vous le mettez à l'épreuve, il fonctionne bien, vous passez à la tâche suivante. Neuf mois plus tard et deux versions plus tard, quelqu'un d'autre apporte une modification à une partie du système. apparemment sans lien avec le programme, et ça casse le module. Pire encore, ils testent leurs modifications et leur code fonctionne, mais ils ne testent pas votre module ; il se peut même qu'ils ne connaissent pas votre module. existe .

Et maintenant vous avez un problème : le code cassé est dans le tronc et personne ne le sait. Dans le meilleur des cas, un testeur interne le trouve avant l'expédition, mais réparer du code aussi tard dans le processus est coûteux. Et si aucun testeur interne ne le trouve... eh bien, cela peut devenir très coûteux en effet.

La solution, ce sont les tests unitaires. Ils détectent les problèmes lorsque vous écrivez du code - ce qui est bien - mais vous auriez pu le faire à la main. La vraie récompense, c'est qu'ils détecteront les problèmes neuf mois plus tard, alors que vous travaillez sur un projet complètement différent, mais qu'un stagiaire d'été pense que ce serait plus ordonné si ces paramètres étaient dans l'ordre alphabétique - et alors le test unitaire que vous avez écrit échoue, et quelqu'un jette des choses au stagiaire jusqu'à ce qu'il change l'ordre des paramètres. C'est le "pourquoi" des tests unitaires :-)

Answer 5

En ce qui concerne les avantages philosophiques des tests unitaires et du TDD, voici quelques-unes des observations clés qui m'ont frappé lors de mes premiers pas sur la route de l'illumination du TDD (aucune n'est originale ou nécessairement nouvelle)...

1. La TDD ne signifie PAS qu'il faut écrire deux fois plus de code. Le code de test est généralement assez rapide et indolore à écrire et constitue un élément clé de votre processus de conception et de critique.

2. TDD vous aide à savoir quand arrêter de coder ! Vos tests vous donnent l'assurance que vous en avez fait assez pour l'instant et que vous pouvez arrêter les modifications et passer à autre chose.

3. Les tests et le code travaillent ensemble pour obtenir un meilleur code. Votre code peut être mauvais / bogué. Votre TEST pourrait être mauvais / bogué. En TDD, vous pariez sur le fait que les chances que les DEUX soient mauvais/buggy sont assez faibles. Souvent, c'est le test qui doit être corrigé, mais cela reste un bon résultat.

4. TDD aide à la constipation du codage. Vous savez, ce sentiment que vous avez tellement de choses à faire que vous savez à peine par où commencer ? On est vendredi après-midi, il suffit de tergiverser quelques heures de plus... Le TDD vous permet d'étoffer très rapidement ce que vous pensez devoir faire, et de faire avancer votre codage rapidement. De plus, comme les rats de laboratoire, je pense que nous réagissons tous à cette grande lumière verte et travaillons plus fort pour la revoir !

5. Dans le même ordre d'idées, ces concepteurs peuvent VOIR ce sur quoi ils travaillent. Ils peuvent s'éloigner pour une pause jus de fruit/cigarette/iphone et revenir à un écran qui leur donne immédiatement un indice visuel de l'endroit où ils sont arrivés. La TDD nous donne quelque chose de similaire. Il est plus facile de voir où nous en sommes arrivés lorsque la vie intervient...

6. Je pense que c'est Fowler qui a dit : "Des tests imparfaits, exécutés fréquemment, sont bien meilleurs que des tests parfaits qui ne sont jamais écrits du tout". J'interprète cela comme me donnant la permission d'écrire des tests là où je pense qu'ils seront les plus utiles, même si le reste de la couverture de mon code est lamentablement incomplète.

7. La TDD est utile dans toutes sortes de domaines surprenants. De bons tests unitaires peuvent aider à documenter ce que quelque chose est censé faire, ils peuvent vous aider à migrer du code d'un projet à l'autre et vous donner un sentiment injustifié de supériorité par rapport à vos collègues non testeurs :)

Cette présentation est une excellente introduction à toutes les bonnes choses que les tests impliquent.