Le développement piloté par les tests (TDD) avec Kiro : voici comment ça devrait se sentir

Au début de ma carrière, l'organisation pour laquelle je travaillais a judicieusement décidé de mettre en œuvre les tests unitaires de façon sérieuse pour améliorer la qualité du code et permettre un refactoring en toute confiance. Nous avons expérimenté la mise en œuvre du développement piloté par les tests (TDD), et bien que nous comprenions les avantages, l'acte de faire du TDD semblait pénible et nous n'arrivions pas à obtenir des ingénieurs qu'ils appliquent les pratiques de façon constante. J'adorais personnellement l'idée du TDD, mais je détestais le travail réel. Dans cet article de blogue, je vais vous montrer comment vous pouvez mettre en œuvre le TDD avec Kiro, et je vais démontrer comment vous pouvez obtenir les avantages du TDD sans la douleur d'écrire manuellement des tests qui suivent le cycle rouge-vert-refactoring.

L'idée de base derrière le développement piloté par les tests est la suivante :

1. Pour chaque nouvelle fonctionnalité que vous construisez, vous identifiez les comportements de la nouvelle fonctionnalité.
2. Vous écrivez ensuite un test pour chacun des nouveaux comportements, qui réussirait si le nouveau comportement existait
3. Vous exécutez les tests, qui devraient tous échouer parce que le comportement n'existe pas encore
4. Vous écrivez le code le plus simple qui réussit le nouveau test
5. Vous effectuez un refactoring selon les besoins, en veillant à ce que tous les tests continuent de réussir

C'est ce qu'on appelle le cycle rouge-vert-refactoring. Vos tests écrits échouent (la phase rouge), vous écrivez du code pour faire réussir les tests (la phase verte), vous continuez à effectuer un refactoring selon les besoins (le cycle de refactoring). Bien que le TDD puisse vous aider à produire du code de haute qualité, il peut être perçu comme chronophage et exige un degré élevé de discipline pour suivre le processus de façon constante.

Bien que j'adorais l'idée du TDD, je détestais le changement de contexte requis pour passer de l'écriture du code de test au code d'implémentation. Je n'aimais pas devoir garder une trace des tests qui avaient été écrits, et honnêtement, je n'aimais pas la monotonie d'écrire tous les tests requis pour bien suivre le TDD. Lorsque je parle à d'autres personnes de leur expérience avec le TDD, je constate souvent que je ne suis pas seul dans mon expérience.

Les outils de développement agentifs comme Kiro éliminent les inconvénients du TDD. Kiro prend en charge le développement piloté par Specs, qui est un flux de travail en trois phases pour guider Kiro à construire la bonne chose de la bonne façon avec la bonne architecture. Chaque Spec se compose de trois phases : une phase des exigences, où Kiro vous aide à définir et à approuver les histoires d'utilisateur et les critères d'acceptation; la phase de conception, où l'architecture technique et l'approche de mise en œuvre sont définies; et la phase des tâches, où sont définies les tâches de mise en œuvre exécutables qui aboutiront à un code qui satisfait l'exigence originale.

En plus du développement piloté par Specs, Kiro prend également en charge les Hooks, qui sont des outils d'automatisation qui s'exécutent automatiquement lorsque des événements précis se produisent dans votre IDE. Par exemple, vous pourriez vouloir créer un Hook pour faire du lint sur le code chaque fois que le fichier est enregistré. En bref, le développement piloté par Specs aide à structurer l'approche d'ingénierie globale, tandis que les Hooks permettent l'application de pratiques précises, comme le TDD.

Dans mon cas, j'ai créé un Hook Kiro pour appuyer mes efforts de TDD.

Ce tutoriel démontre les capacités de TDD de Kiro à l'aide de requêtes d'exemple à des fins éducatives. Si vous adaptez cette approche pour des systèmes de production, gardez les points suivants à l'esprit.

• Révisez toujours le code généré par l'IA pour détecter les vulnérabilités de sécurité avant le déploiement, en particulier la logique d'authentification, d'autorisation, de validation des entrées et de traitement des données. Testez dans divers scénarios pour vérifier que le code se comporte correctement.
• L'exemple utilise une API ouverte sans authentification pour simplifier les choses, mais les déploiements en production nécessitent des contrôles de sécurité complets : authentification et autorisation, chiffrement HTTPS/TLS, chiffrement au repos, validation des entrées, limitation du débit, journalisation complète et gestion des secrets pour les identifiants.
• Les organisations qui adoptent des outils de développement en IA devraient également établir des politiques de gouvernance concernant l'accès, la surveillance de la qualité du code et les processus de validation.

Pour des conseils de sécurité complets, consultez l'équipe de sécurité de votre organisation et consultez la documentation des bonnes pratiques de sécurité d'AWS.

Vous pouvez créer un Hook dans Kiro en naviguant vers l'onglet Kiro et en cliquant sur le bouton « + » dans la fenêtre agent hooks et en sélectionnant manually create a hook. Dans la fenêtre qui apparaît, j'entre ce qui suit :

• Titre : TDD: Test First
• Description : Enforces Test-Driven Development by prompting to write failing tests before any production code. Follows the red/green/refactor cycle: write a test that fails (red), write minimal code to pass (green), then refactor.
• Événement : Pre Tool Use
• Nom de l'outil : write
• Action : Ask Kiro
• Instructions pour l'agent Kiro :

Faites défiler jusqu'au bas de l'écran et cliquez sur Create Hook.

Ce Hook s'exécute chaque fois que Kiro tente d'enregistrer un fichier. Il vérifie que le cycle rouge-vert-refactoring est suivi pendant qu'il écrit du code.

À titre de test simple, je demande à Kiro d'écrire un programme qui démontre le problème de Monty Hall. Kiro écrit des tests unitaires, ils échouent, puis Kiro réalise qu'ils ont échoué parce que les modules correspondants n'existent pas encore. Selon le Hook, les tests doivent échouer en raison d'échecs d'assertion, alors il crée les modules de base et vérifie que les tests échouent maintenant en raison d'erreurs d'assertion. Il écrit ensuite le code minimal pour faire réussir les tests.

Cet exemple simple montre que le Hook fonctionne, mais voyons comment il gère quelque chose de plus réaliste : construire une API REST de production.

Construire une API basée sur REST

Pour écrire du vrai code, j'ai commencé une session Spec de Kiro et j'ai entré des exigences pour construire une API basée sur REST pour un système de gestion de tâches. Mon document d'exigences final est disponible ci-dessous.

Une fois que Kiro a les exigences, il peut les synthétiser en un document de conception et finalement en une liste de tâches. Au fur et à mesure que j'exécute chaque tâche, le Hook TDD force Kiro à travailler à travers le cycle rouge-vert-refactoring pour chaque tâche.

À titre d'exemple, je demande à Kiro d'exécuter une tâche pour construire le gestionnaire de route GET /tasks/{task_id} de mon API. Kiro identifie qu'il doit construire des tests en échec avant d'écrire le code pour appuyer cette fonction.

Kiro construit les tests et confirme qu'ils échouent, ce qui signifie qu'il a terminé avec succès la phase rouge. Il modifie ensuite le code et réexécute les tests pour confirmer qu'ils réussissent maintenant, ce qui confirme qu'il a terminé avec succès la phase verte. Une fois que les nouveaux tests réussissent, Kiro réexécute tous les tests pour vérifier qu'ils continuent tous de fonctionner correctement.

Pendant des années, j'ai lutté avec le TDD. Je croyais aux avantages comme une meilleure qualité de code, moins de bogues et plus de confiance dans le refactoring; mais la réalité de la chose était épuisante. Le changement de contexte constant, la discipline requise pour rester dans le cycle rouge-vert-refactoring et la douleur d'écrire des tests avant la mise en œuvre faisaient en sorte que le TDD semblait être un fardeau plutôt qu'une pratique bénéfique.

Kiro change complètement la donne. En utilisant un simple Hook, j'ai automatisé la discipline qu'exige le TDD. Avec les Hooks, Kiro ne me laisse pas sauter des étapes ou prendre des raccourcis. Il applique le cycle sans que j'aie besoin d'y penser. J'obtiens les avantages du TDD sans le fardeau du changement de contexte, la discipline pour respecter le processus et la monotonie d'écrire de bons tests. Comme je l'ai démontré dans cet article, que j'écrive une simple démonstration comme le problème de Monty Hall ou que je construise une API REST prête pour la production avec des dizaines d'exigences, les Hooks appliquent le processus de TDD.

Pour moi, c'est ce que le TDD devrait sentir : Kiro me donne tous les avantages sans le fardeau.

Si vous voulez essayer cette approche vous-même, copiez la configuration du Hook de cet article et utilisez-la avec vos projets Kiro. Commencez par un petit projet, voyez comment ça se sent, et ajustez les instructions du Hook pour correspondre à votre flux de travail. Si vous avez eu du mal avec le TDD dans le passé ou si vous cherchez un moyen d'améliorer la qualité de votre code, donnez une chance au TDD avec les Hooks Kiro.