Existe-t-il une différence entre TDD et Test First Development (ou Test First Programming)?
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?
Il y a une différence en ce qui concerne le facteur déterminant.
Avez-vous une idée vague 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 le test d'abord le développement.
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 est-ce que je veux donner?"
Ce sont des noms fondamentalement différents qui décrivent la même chose - bien, en fait, cinq noms, le dernier D pouvant signifier Design ainsi que Développement.
Test d'abord é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.
À l’évidence, aujourd’hui, certaines personnes ont des connotations différentes pour ces deux termes, mais ce n’était pas l’intention qui sous-tendait leur existence. En fait, je préférerais que le terme TFD soit obsolète.
Il existe de nombreux termes similaires tels que programmation d'abord test, développement test d'abord, développement piloté par les tests ou même conception pilotée par les tests. Il est important de clarifier quelques points:
1. Tester 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 «Extreme Programming Explained»: «Écrivez les tests unitaires avant la programmation 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 dirigé par les tests (TDD)
Le développement piloté par les tests (TDD) est le nom d'une méthodologie introduite 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 la programmation test-first. 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.
TDD = TFD + Refactoring.
Lorsque vous utilisez TFD, vous appliquez une refactorisation pour rendre le code plus générique et plus robuste.
Historiquement correct: la programmation d'abord testée et le développement piloté par les tests signifient «Même chose avec un nom amélioré»
Dans le contexte de XP (programmation extrême), processus de développement de logiciels qui a rendu populaire la programmation test-first et le développement piloté par les tests, la programmation test-first a été renommée développement piloté par les tests, puis test-test. Driven Design après avoir réalisé que l'écriture de tests avait 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
- Indépendamment déployable
- Développable indépendamment
- Indépendamment raisonnable
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. La rédaction de 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 logicielles est devenue si importante, outre les autres effets positifs, que les créateurs ont jugé intéressant de la renommer de Programmation test-en premier à Développement piloté par les tests.
Le nom Test-Driven Development aide également à commercialiser la méthode mieux en termes d’acceptation et de compréhension, car le nom Test-Driven Development met davantage l’accent 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:
Programmation Test-First…
… Est une méthode dans laquelle des tests pour le code sous test sont écrits avant le code sous test.
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:
- Vous ne pouvez écrire aucun code de production avant d'avoir écrit un test unitaire défaillant.
- Vous ne pouvez pas écrire plus d'un test unitaire que ce qui est suffisant pour échouer, et la compilation échoue.
- Vous ne pouvez pas écrire plus de code de production que ce qui est suffisant pour réussir le test unitaire actuellement en échec. - Robert C. Martin, Les trois lois du développement piloté par les tests
Suivre 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 le refactoriser sans merci 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.
Au fait, si vos tests vous empêchent de vous refactoriser, vos tests sont de niveau trop bas, trop étroitement couplés et peut-être que vous avez utilisé trop de railleries.
Autres renomages intéressants dans Extreme Programming
- 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 trop littéralement et que les gens s'arrêtaient avant d'avoir terminé.
- Refactoring continu -> Amélioration continue de la conception; La refactorisation n’est pas un moyen de parvenir à une fin en soi, mais elle poursuit un objectif plus élevé.
- Semaine de 40 heures -> Sustainable Pace (légende urbaine: ce changement de nom a eu lieu après des manifestations de développeurs de logiciels français.)
Ils sont exactement la même chose. Les deux références écrivent des tests d'abord, 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 testent.
Développement dans Test Driven: 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.