Différence entre les tests unitaires et le développement piloté par les tests
De la lecture des descriptions, je comprends que dans les tests TDD sont effectués avant d'écrire la fonction et dans Unit Testing, c'est fait après.
Est-ce la principale différence, 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 de TDD.
Test unitaire fait référence à quoi vous testez, TDD à quand vous testez.
Les deux sont orthogonaux.
Le test unitaire signifie, bien, tester des unités de comportement individuelles. Une unité de comportement individuelle est la plus petite unité de comportement possible qui peut être testée individuellement de manière isolée. (Je sais que ces deux définitions sont circulaires, mais elles semblent très bien fonctionner dans la pratique.)
Vous pouvez écrire des tests unitaires avant d'écrire votre code, après avoir écrit votre code ou pendant que vous écrivez votre code.
TDD signifie (encore une fois, c'est évident) de laisser vos tests piloter 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 milieu D . Vous laissez les tests conduire vous. Les tests vous disent quoi faire, quoi faire ensuite, lorsque vous avez terminé. Ils vous disent ce que l'API va être, quelle est la conception. (Ceci est important: TDD ne consiste pas à écrire des tests en premier. Il existe de nombreux projets qui écrivent des tests en premier mais ne pratiquent pas TDD. L'écriture de tests en premier est simplement une condition préalable pour pouvoir laisser les tests conduire le développement.)
Les tests unitaires sont 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 de tests unitaires.
Lorsque vous effectuez des tests unitaires traditionnels , vous écrivez test après vous avez écrit votre code.
L'approche de développement piloté par les tests consiste à écrire le test unitaire avant d'écrire du code.
Avantages les plus intéressants du TDD (IMHO) par rapport aux tests unitaires simples:
- Le code est entièrement testé à l'avance. C'est un test indolore.
- Cela vous oblige à concevoir correctement vos classes.
- Cela vous oblige également à garder les choses stupides .
- Le cycle de Red-Green-Refactor est le tueur absolu de procrastination!
TDD et Unit Testing sont deux termes très spécifiques qui sont souvent mal utilisés.
TDD écrit un test qui échouera, puis écrit la quantité minimale de code requise pour le faire fonctionner, puis refactorise le code pour le rendre propre. Cela se fait par cycles, échec -> réussite -> refactoriser, en ajoutant un nouveau test pour chaque exigence connue pour le code. Plus récemment, TDD est devenu encore plus spécifiquement sur l'écriture de tests unitaires dans ce cycle, pour le distinguer d'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 courante ici est de penser que si vous utilisez un outil de test unitaire, tel que xUnit ou Rspec, pour exécuter des tests que vous écrivez des tests unitaires. Ce n'est pas nécessairement vrai. Ces outils peuvent être utilisés pour exécuter, par exemple, des tests à l'aide du framework Selenium - dans ce cas, vous écrivez des tests d'acceptation à l'aide d'un lanceur de tests unitaires. Les tests unitaires sont très spécifiquement des tests qui se concentrent sur un petit morceau de logique, isolé de tout le reste pour des raisons de vitesse (afin que vous puissiez les exécuter souvent et obtenir un retour rapide sur les nouveaux bugs).
TDD est l'approche consistant à écrire les cas de test avant le développement, comme vous l'avez dit, puis le développeur écrit le code pour passer les cas de test. Les tests unitaires sont un terme utilisé pour décrire un type de test de portée étroite autre que les tests système, les tests d'intégration et les tests d'acceptation.
TDD est une approche philosophique de l'écriture de code: écrivez d'abord les tests. Les tests que vous écrivez sont des tests unitaires.
Toutes d'excellentes réponses. J'ajouterais seulement que les tests unitaires ont tendance à considérer l '"unité" comme un petit composant, tandis que TDD évolue pour inclure les tests d'intégration et d'acceptation.
(Certaines variantes TDD considèrent l '"unité" comme la plus petite étape incrémentielle vers la fonctionnalité souhaitée ...)
La façon dont je sépare les deux est de considérer que TDD est moins sur les tests que sur la conception du code. Des tests unitaires sont ensuite utilisés pour définir les attentes pour le code final. Lorsque le code de fin est écrit et passe des tests (spécifications), vous disposez d'un code conçu à l'aide de tests.