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.
Réponses:
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.)
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:
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).
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.
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.
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 ...)