Différence entre les tests unitaires et le développement piloté par les tests

64

D'après la lecture des descriptions, je comprends que les tests TDD sont effectués avant l'écriture de la fonction et que les tests unitaires sont effectués ensuite.

Est-ce la différence principale, ou les deux termes ne peuvent même pas être comparés en tant que tels. Peut-être que les tests unitaires font partie intégrante du TDD.

Shamim Hafiz
la source

Réponses:

104

Tests unitaires se réfère à ce que vous testez, TDD à quand vous testez.

Les deux sont orthogonaux.

Les tests unitaires signifient, bien, tester des unités individuelles de comportement. Une unité individuelle de comportement est la plus petite unité de comportement qui puisse être testée individuellement de manière isolée. (Je sais que ces deux définitions sont circulaires, mais elles semblent bien fonctionner dans la pratique.)

Vous pouvez écrire des tests unitaires avant d'écrire votre code, après l'écriture de votre code ou pendant que vous écrivez votre code.

TDD signifie (encore une fois, assez évident) laisser vos tests guider votre développement (et votre conception). Vous pouvez le faire avec des tests unitaires, des tests fonctionnels et des tests d'acceptation. Habituellement, vous utilisez les trois.

La partie la plus importante de TDD est le D moyen . Vous laissez les tests vous conduire . Les tests vous disent quoi faire, quoi faire ensuite, quand vous avez terminé. Ils vous disent ce que sera l'API, ce que sera la conception. (Ceci est important: TDD ne consiste pas à écrire des tests en premier. De nombreux projets écrivent des tests en premier mais ne le pratiquent pas. Écrire des tests en premier est simplement une condition préalable pour pouvoir laisser les tests piloter le développement.)

Jörg W Mittag
la source
1
Très bonne réponse. ajouterais ... TDD, c’est quand vous laissez les tests vous pousser et les fonctionnalités pour tirer vos efforts de développement ...
Martin
Ils ne sont pas orthogonaux cependant. Vous ne pouvez pas avoir TDD sans tests unitaires.
JacquesB
1
@ JacquesB, pourquoi? Nos tests ne sont pas ce que vous appelleriez des tests unitaires, quelle que soit leur définition. Ils dépendent trop de l’infrastructure et d’autres composants, mais nous avons toujours suffisamment d’observabilité pour que nous - du moins certains d’entre nous - effectuions le TDD.
AProgrammer
3
@AndrewWillems: TDD signifie que les tests pilotent le développement . Vous ne décidez pas de quoi le design ressemble, les tests vous le diront. Vous ne décidez pas sur quoi travailler ensuite, les tests vous le disent. Vous ne décidez pas quand vous avez fini, les tests vous le disent. Il est parfaitement possible d’écrire d’abord des tests, puis d’ignorer tout ce qu’ils vous disent. Par exemple, vous pouvez commencer par écrire des tests, puis continuer à écrire du code même après que tous les tests sont verts. En d'autres termes, vous écrivez d'abord des tests, mais vous les traitez comme des tests et vous ne les laissez pas diriger le développement.
Jörg W Mittag Le
1
@ JörgWMittag Vous avez peut-être raison de le regarder de façon puriste, mais vous savez aussi que le TDD n'est pas en noir et blanc. Toute utilisation rationnelle de TDD ne laisserait pas les tests guider complètement le développement, et les tests ne décident certainement pas toujours à quoi ressemble le design (peut-être que les tests unitaires peuvent le faire en partie, mais pas les tests à un niveau d'abstraction plus élevé). Qu'en est-il du refactoring? Ce qui est un aspect très important du TDD. De même, dans le monde réel, il n’existe pas de «ignorer tout ce que le test vous dit». Par définition, si vous écrivez d’abord des tests, vous utilisez «une certaine forme de TDD».
NickL
21

Le test unitaire est une composante du développement piloté par les tests

Vous pouvez effectuer des tests unitaires sans effectuer de développement piloté par les tests. Cependant, vous ne pouvez pas faire de développement piloté par les tests sans utiliser les tests unitaires.

Lorsque vous effectuez des tests unitaires traditionnels , vous écrivez test après avoir écrit votre code.

L' approche du développement piloté par les tests consiste à écrire des tests unitaires avant d' écrire du code.

Les avantages les plus intéressants du TDD (IMHO) par rapport au test unitaire simple:

  • Le code est entièrement testé dès le départ. C'est un test indolore.
  • Cela vous oblige à concevoir correctement vos classes.
  • Cela vous oblige également à garder les choses simples et stupides .
  • Le cycle de Red-Green-Refactor est le tueur absolu de la procrastination!

la source
Avez-vous oublié «unité» à dessein dans la déclaration: «Cependant, vous ne pouvez pas faire de développement piloté par les tests sans utiliser les tests. ?
ratkok
@ratkok: non, ce n'était pas fait exprès. Laisse-moi réparer ça.
J'aime cette définition le meilleur. Il vaut mieux écrire avec des mots que d’autres réponses.
Tek
2
On peut soutenir que vous pouvez utiliser TDD en utilisant des tests de module ou des tests système plutôt que de véritables tests unitaires. Je ne le conseillerais pas, car vous perdriez beaucoup de votre bénéfice si les tests mettent trop de temps à se dérouler, mais ce n'est pas impossible.
Toby Speight
13

TDD et Unit Testing sont deux termes très spécifiques qui sont souvent mal utilisés.

TDD est en train d'écrire un test qui échouera, puis en écrivant la quantité minimale de code nécessaire pour le faire fonctionner, puis en refacturant le code pour le nettoyer. Cela se fait en cycles, échec -> réussite -> refacteur, en ajoutant un nouveau test pour chaque exigence connue du code. Plus récemment, TDD est devenu encore plus spécifiquement responsable de l'écriture de tests unitaires dans ce cycle, afin de le distinguer de ATDD (un sous-ensemble de BDD) qui écrit des tests d'acceptation dans un cycle similaire.

Le test unitaire consiste à tester un code dans de petites unités isolées. La confusion qui règne ici est de penser que si vous utilisez un outil de test unitaire, tel que xUnit ou Rspec, pour exécuter des tests, écrivez des tests unitaires. Ce n'est pas forcément vrai. Ces outils peuvent être utilisés pour exécuter des tests en utilisant le framework Selenium. Dans ce cas, vous écrivez des tests d'acceptation à l'aide d'un programme d'exécution de tests unitaires. Les tests unitaires sont très spécifiquement des tests qui se concentrent sur un petit élément de logique, isolé de tout le reste pour des raisons de rapidité (afin que vous puissiez les exécuter souvent et obtenir un retour rapide sur les nouveaux bogues).

pdr
la source
1
Les tests JUnit pour JUnit lui-même en sont un bon exemple: une part importante de ceux-ci sont des tests fonctionnels et des tests d'acceptation, et non des tests unitaires, même s'ils sont écrits en JUnit. En outre, le créateur de JUnit se trouve être également le créateur de TDD, et JUnit a été développé à l'aide de TDD en utilisant un nombre important de tests fonctionnels et de tests d'acceptation. Les tests d'acceptation font partie intégrante du TDD.
Jörg W Mittag
6

TDD consiste à écrire les scénarios de test avant le développement, comme vous l'avez dit, puis le développeur écrit le code pour réussir les scénarios de test. Le test unitaire est un terme utilisé pour décrire un type de test à portée limitée autre que le test du système, le test d'intégration et le test d'acceptation.

M.Sameer
la source
3

TDD est une approche philosophique de l'écriture de code: écrivez d'abord les tests. Les tests que vous écrivez sont des tests unitaires.

Tangurena
la source
1

La manière dont je sépare les deux est de considérer que TDD est moins axé sur les tests que sur la conception du code. Les tests unitaires sont ensuite utilisés pour définir les attentes pour le code de fin. Lorsque le code final est écrit et qu'il réussit les tests (spécifications), vous disposez d'un code conçu à l'aide de tests.

Grant Palin
la source
1

Toutes les réponses sont excellentes. J'ajouterai seulement que les tests unitaires ont tendance à considérer l'unité comme une petite composante, tandis que le TDD est étendu pour inclure des tests d'intégration et d'acceptation.

(Certaines variantes de TDD considèrent l'unité comme la plus petite étape vers la fonctionnalité désirée ...)

Steven A. Lowe
la source
ils devraient, mais dans mon expérience en réalité ils ne le font pas. Les entreprises et les groupes disent qu'ils utilisent le TDD, lorsqu'ils ne font que forcer les programmeurs à commencer les tests avec les tests jUnit, puis utilisent le fait que tout a déjà été testé au cours du développement pour supprimer (ou réduire considérablement) les tests d'assurance qualité et d'intégration.
Jwenting
1
@jwenting ne blâme pas la méthodologie pour les défauts de ceux qui prétendent la pratiquer. n'importe quel outil peut être mal utilisé
Steven A. Lowe
1
Moi non, mais vous devez comprendre qu’il ya une grande différence entre ce que TDD est en théorie et ce qu’il est en réalité. Et comme la plupart des gens (y compris les OP) ne voient probablement que la réalité, il faut leur montrer la différence.
Jwenting
Considérant que le TDD concerne la conception, pourquoi devrait-il inclure des tests d'acceptation? comment cela "conduirait-il" le design?
Vitalii Isaenko
Les tests de réception de @VitaliiIsaenko fournissent une définition de la plus haute portée pour les conceptions
Steven A. Lowe