Existe-t-il une différence entre TDD et Test First Development (ou Test First Programming)?

Question

Les deux idées me semblent très semblables, mais il peut y avoir des différences subtiles ou la même chose, expliquée de différentes manières. Quelle est la relation entre TDD et Test First Development / Programming?

Answer 1

Il existe une différence en ce qui concerne le facteur déterminant.

Avez-vous une vague idée de ce à quoi devrait ressembler la classe (ou le système - cela peut se produire à différentes échelles, bien sûr), puis imaginez des tests qui lui donnent la forme réelle? C'est TDD.

Savez-vous exactement ce que devrait être l'API publique de la classe et écrivez simplement les tests avant la mise en œuvre? C’est un développement d’essai d’abord.

Mon style a tendance à être un mélange des deux. Parfois, il est évident que l’API doit être avant d’écrire des tests. Dans d’autres cas, la testabilité détermine réellement la conception.

En d'autres termes, TDD commence par "Quelles questions dois-je poser?" alors que non-TDD (que ce soit le test en premier ou non) commence par "Quelle réponse dois-je donner?"

Answer 2

Ce sont des noms fondamentalement différents qui décrivent la même chose - en fait, cinq noms, le dernier D pouvant signifier Design ainsi que Développement.

Test First était le terme utilisé à l'origine, en particulier dans le contexte de la programmation extrême, pour le cycle de refactorisation du code de test. Le nom Test Driven Development a été proposé - et adopté rapidement - plus tard, pour souligner le fait que le TFD est - et a toujours été - davantage une stratégie de conception que une stratégie de test.

De nos jours, certaines personnes ont des connotations différentes pour ces deux termes, mais ce n’était pas l’intention qui sous-tendait leur existence, et je ne me fierais pas à ce qu’il soit de notoriété publique (car ce n’est pas le cas). En fait, je préférerais que le terme TFD soit obsolète.

Answer 3

Il existe de nombreux termes similaires tels que programmation test-first, développement test-first, développement piloté par les tests ou même conception pilotée par les tests. Il est important de clarifier quelques points:

1. Test de la première programmation (TFP)

Le terme programmation «test-first» est une pratique exemplaire en matière de programmation. Il a été réintroduit (s'il n'a pas été inventé) par Kent Beck dans son livre "Expliquez la programmation extrême" & "8221 ;:" et # 8220; écrivez des tests unitaires avant de programmer et maintenez tous les tests actifs à tout moment ". Ainsi, lorsque nous parlons de programmation d'abord avec les tests, nous parlons d'écrire des tests unitaires automatisés par le développeur même qui écrira le code pour satisfaire ces tests. Les tests unitaires s’empilent et créent une suite de tests de régression automatisée pouvant être exécutée périodiquement.

2. Développement piloté par les tests (TDD)

Le développement piloté par les tests (TDD) est le nom d’une méthodologie présentée par Kent Beck dans son livre "Test Driven Development by Example". C'est un processus de développement logiciel, il ne s'agit pas seulement d'écrire des tests avant le code. Tout le livre tente de l'expliquer par des schémas, des flux de travail, une culture, etc. L’un des aspects importants est l’accent mis sur la refactorisation.

Certaines personnes utilisent les termes développement test-premier, conception pilotée par test ou programmation pilotée par test, etc. Une chose est sûre: la méthodologie bien établie est le développement piloté par test et la technique de programmation est le test d'abord. la programmation. Les autres font généralement référence à l’idée d’écrire des tests avant le code ou font référence à tort au développement piloté par les tests ou à la programmation d’essais en premier.

Answer 4

TDD = TFD + Refactoring.

Lorsque vous utilisez TFD, vous appliquez une refactorisation pour rendre le code plus générique et plus robuste.

Answer 5

Historiquement correct: la programmation par test et le développement piloté par test signifient "Idem avec un nom amélioré"

Dans le contexte de XP (Extreme Programming), processus de développement logiciel qui a rendu populaire la programmation test-first et le développement piloté par les tests, la programmation test-first a été renommée en développement piloté par les tests, puis suivant: la prise de conscience que l'écriture de tests a d'abord un effet extrêmement positif sur l'architecture logicielle et la conception d'un système logiciel.

Cette influence sur l’architecture et le design est la conséquence de synonymes plus ou moins surprenants:

• Testable
• découplé
• réutilisable
• déployable indépendamment
• Développable indépendamment
• Indépendamment raisonnables

Les entités logicielles ne peuvent être facilement réutilisées, testées, déployées indépendamment, développées indépendamment ou raisonnées facilement séparément si elles sont découplées. Écrire des tests avant la mise en œuvre effective est une méthode presque irréprochable pour assurer un découplage continu.

Cette influence sur la conception et l’architecture du logiciel est devenue si importante, outre les autres effets positifs, que les créateurs ont jugé utile de le renommer de Programmation test-en premier à Développement piloté par les tests.

Le nom Test-Driven Development facilite également la commercialisation de la méthode en termes d’acceptation et de compréhension, car le nom Test-Driven Development insiste mieux sur les aspects holistiques de la méthode que Test-First Programming.

Pas historiquement correct mais utile

Bien qu'historiquement non correct, je trouve la distinction suivante très utile:

Programmer d'abord le test…

… est une méthode dans laquelle les tests du code sous test sont écrits avant le code sous test.

Le développement piloté par les tests…

… est un sous-ensemble spécifique de la programmation «Test First» qui suit les 3 lois du développement piloté par les tests, décrites par Robert C. Martin:

  

  
1. Vous ne pouvez pas écrire de code de production avant d'avoir écrit un test unitaire défaillant.
  
2. Vous ne pouvez pas écrire plus d'un test unitaire que suffisant pour échouer, et la compilation échoue.
  
3. Vous ne pouvez pas écrire plus de code de production que ce qui est suffisant pour réussir le test unitaire en échec.   - Robert C. Martin, Les trois lois du développement piloté par les tests
  

Le respect de ces trois règles vous place dans ce que l’on appelle le cycle Red-Green-Refactor. 1. Vous écrivez un test qui échoue. 2. Vous le faites passer. 3. Maintenant que le test est réussi, vous pouvez refactoriser impitoyablement avant d'écrire le prochain test qui échoue.

Notez que le refactoring nécessite des tests en toute sécurité. Refactoriser signifie changer la structure du code source sans changer le comportement significatif. Mais comment savons-nous que nous n'avons pas accidentellement modifié un comportement significatif? Qu'est-ce qui définit un comportement significatif? C’est l’une des nombreuses choses pour lesquelles les tests sont utiles.

Si vos tests vous empêchent de vous refactoriser, vos tests sont trop bas, trop couplés, et peut-être avez-vous trop utilisé la moquerie.

Autres renommage intéressants en programmation extrême

• Intégration continue - > Livraison continue - > Déploiement continu; Strictement parlant, ils signifient différentes choses. Cependant, dans l'esprit de XP, cela signifiait un déploiement continu dès le début, et lorsque les gens ont pris le train en marche, on s'est rendu compte que l'intégration était prise à la lettre et que les gens s'arrêtaient avant d'avoir terminé.
• Refactoring continu - > Amélioration continue de la conception; Le refactoring n’est pas un moyen de parvenir à une fin en soi, mais poursuit un but plus élevé.

Ils sont exactement la même chose. Les deux références écrivent d’abord les tests, puis écrivent le code qui passera le test

TDD (Test Driven Development) est Test First Development / Programming bien que j’ai déjà vu et entendu TDD voulait dire créer des tests unitaires persistants et répétables (même après le code), mais cela implique en réalité que les tests sont écrits avant le code qu’ils ont testons.

Dans Le développement piloté par les tests: par exemple , l'auteur, Kent Beck , indique clairement que "tester d'abord" (TF) est la règle. Donc, TF est le principe qui régit le TDD. Le dernier est le processus.

Answer 6

Ils sont exactement la même chose. Les deux références écrivent d’abord les tests, puis écrivent le code qui passera le test

Answer 7

TDD (Test Driven Development) est Test First Development / Programming bien que j’ai déjà vu et entendu TDD voulait dire créer des tests unitaires persistants et répétables (même après le code), mais cela implique en réalité que les tests sont écrits avant le code qu’ils ont testons.

Answer 8

Dans Le développement piloté par les tests: par exemple , l'auteur, Kent Beck , indique clairement que "tester d'abord" (TF) est la règle. Donc, TF est le principe qui régit le TDD. Le dernier est le processus.