Développement piloté par des tests multilingues

La courte question: comment suivez-vous le développement piloté par les tests sur un projet qui couvre plusieurs langues?

Plus précisément, j'écris une application Web qui utilise JavaScript et PHP, et je veux suivre les principes TDD, mais je ne sais pas comment les intégrer. Dois-je exécuter des suites de tests distinctes pour les sections JS et PHP et utiliser des maquettes dans la suite JS pour émuler les réponses du serveur? Existe-t-il une technique pour tester les deux composants en une seule fois?

Il s'agit de ma première expérience d'utilisation du développement piloté par les tests, donc tout conseil que vous pourriez partager sur la façon de le rendre moins intimidant serait formidable. La raison pour laquelle je l'ai choisi est que dès que j'ai terminé un prototype, les exigences ont changé, m'obligeant à changer ma conception. Je me suis dit que si je recommençais, j'aimerais écrire du code plus extensible avec des tests de régression intégrés dès le départ.

J'écris mes tests PHP dans SimpleTest et mes tests JavaScript dans JsTestDriver. Je suis habitué aux paradigmes orientés objet, j'ai donc quelques classes en PHP, et je fais quelque chose de similaire en JavaScript en utilisant l'héritage prototypique. J'ai également commencé à lire ce livre sur TDD en Python et celui-ci sur TDD en JavaScript , mais d'après tout ce que j'ai vu, ceux-ci ne décrivent pas le test complet d'une application (en dehors de l'utilisation de quelque chose comme Selenium ou un autre pilote Web pour effectuer des tests d'acceptation frontaux. Le TDD n'est-il tout simplement pas conçu pour les développeurs à pile complète?

Existe-t-il une technique pour tester les deux composants en une seule fois?

Ce serait en fait l'opposé du test unitaire - le test unitaire, en particulier dans le style TDD, signifie tester vos composants de manière isolée . Ainsi, la réponse est oui, "exécutez des suites de tests distinctes pour les sections JS et PHP ", sinon ce ne sont pas des tests unitaires et pas TDD.

Bien sûr, les tests d' intégration automatisés peuvent tester "les deux composants en une seule fois", et vous pouvez utiliser exactement les outils que vous avez déjà mentionnés (comme Selenium). Mais ce sont généralement des tests plus complexes, développés en dehors des cycles TDD.

L'important est de faire la distinction entre TDD et ATDD . L'AT signifie « tests d' acceptation », et cela fait référence au développement où vous commencez d'abord par un test d'acceptation, qui est susceptible de tester la pile entière. Ceci est aussi parfois appelé «développement piloté par des tests externes». Lorsque les gens parlent de TDD, le «T» fait probablement référence spécifiquement aux tests unitaires .

Un élément clé des tests unitaires consiste à isoler l'unité sous test de ses dépendances. Cela vous donne deux avantages très importants:

• Vous pouvez rendre vos tests extrêmement rapides, vous pouvez donc les exécuter très souvent dans le cadre d'un cycle de rétroaction très court. Plutôt que de les exécuter, disons, toutes les heures, vous devriez pouvoir exécuter tous vos tests unitaires après chaque petit changement, de sorte que vous obtenez instantanément leurs commentaires sur si ce changement a cassé quoi que ce soit.

• Vos tests peuvent cibler à la fois des comportements très spécifiques. Si l'un d'eux échoue, vous devriez être en mesure de déterminer presque instantanément la nature exacte du bogue que le test indique.

En raison de l'importance de cet isolement, vous souhaiterez automatiquement que les tests soient limités à des unités beaucoup plus petites que vos limites linguistiques ne vous y obligent. Bien que ce ne soit pas une règle stricte et rapide, vous vous attendez souvent à ce qu'une seule classe soit une unité testable. Donc, en termes de TDD, la question de la langue est plus ou moins hors de propos.

Si, d'autre part, vous voulez faire de l'ATDD, assurez-vous de regarder spécifiquement les ressources pour cela (cela est souvent fait dans le cadre du BDD, alors regardez les outils ciblés aussi). Voici où quelque chose comme Selenium pourrait naturellement s'intégrer. Habituellement, lorsque vous faites ATDD, vous écrivez toujours des tests unitaires, et en fait, pour réussir chaque test d'acceptation, vous pouvez également tester sa mise en œuvre avec des tests unitaires. Donc, même si vous voulez faire de l'ATDD, il est toujours important de comprendre comment écrire des tests unitaires.

Vous n'avez pas non plus à utiliser TDD pour la pile complète de l'application. TDD en tant que méthodologie de développement est plus adapté aux parties logiques d'une application. Les parties qui nécessitent une touche plus expérimentale, comme le dit la conception du frontend, certaines interactions ou le domaine de la base de données, sont mieux faites dans un style traditionnel car vous ne savez pas encore si ce sera la version finale.

Mais la logique de l'application ne devrait pas changer à l'avenir, et si c'est le cas, vous êtes confronté au fluage des exigences tant redouté. Cela le rend parfait pour une suite de tests de régression pour donner confiance chaque fois que vous modifiez le code, ce qui est l'objectif ultime de TDD.

L'oncle Bob m'explique mieux ainsi que moi. https://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html