Skip to main content
1

Créer un playbook pour l’écriture des tests

Votre monorepo e-commerce comporte plus de 30 modules, mais seuls quelques-uns disposent d’une couverture de tests significative. Vous voulez passer de 44 % de couverture globale à 80 % — en commençant par les 8 modules les moins bien couverts. Avant de lancer des sessions parallèles, vous avez besoin d’un playbook qui garantit que les 8 sessions écrivent les tests de la même manière.Demandez à Devin de créer le playbook pour vous — décrivez simplement vos conventions de test dans n’importe quelle session :Ce playbook devient l’ensemble d’instructions partagé pour chaque session parallèle. Vous pouvez également ajouter des entrées Knowledge à propos de vos utilitaires de test, de vos modèles de mocking ou de toute particularité propre au projet (par exemple, “always call resetMocks() in afterEach”).
2

Lancez 8 sessions parallèles à 18 h

À la fin de votre journée de travail, ouvrez une nouvelle session Devin depuis la page d’accueil de Devin et décrivez la tâche de traitement par lots.
  1. Sélectionnez votre playbook d’écriture de tests dans la liste déroulante
  2. Décrivez la tâche dans le prompt :
  1. Passez en revue les sessions proposées — Devin répertorie chaque module avec sa couverture actuelle et indique quelles sessions il va créer :
Proposed sessions (8 modules, all below 50% coverage):
  1. src/services/PaymentService — 31% coverage
  2. src/services/UserService — 38% coverage
  3. src/api/routes/billing — 42% coverage
  4. src/middleware/auth — 44% coverage
  5. src/services/NotificationSvc — 47% coverage
  6. src/components/Checkout — 49% coverage
  7. src/utils/validation — 51% coverage
  8. src/services/SearchService — 53% coverage

Start 8 parallel sessions? (y/n)
  1. Validez le lot et fermez votre ordinateur portable. Les 8 sessions démarrent simultanément sur des machines Devin distinctes, chacune suivant votre playbook indépendamment.
3

Réveillez-vous avec jusqu’à 8 PR

Le matin, chaque session sera terminée et aura ouvert sa propre pull request (PR). Vous verrez 8 PR dans votre dépôt, chacune contenant de nouveaux fichiers de test et un récapitulatif de la couverture de tests :
Module                       | Before | After  | PR     | Status
-----------------------------|--------|--------|--------|--------
src/services/PaymentService  |  31%   |  87%   | #412   | Ready
src/services/UserService     |  38%   |  84%   | #413   | Ready
src/api/routes/billing       |  42%   |  91%   | #414   | Ready
src/middleware/auth           |  44%   |  82%   | #415   | Ready
src/services/NotificationSvc |  47%   |  85%   | #416   | Ready
src/components/Checkout      |  49%   |  83%   | #417   | Ready
src/utils/validation         |  51%   |  93%   | #418   | Ready
src/services/SearchService   |  53%   |  86%   | #419   | Ready

Overall coverage: 44% -> 68% (+24 pts across targeted modules)
Fusionnez les PRs dans n’importe quel ordre — comme chaque session ne fait qu’ajouter de nouveaux fichiers de test à son propre module, les conflits sont rares. Si deux sessions ont modifié un helper de test partagé, résolvez le conflit manuellement ou demandez à Devin de le corriger.
4

Lancez un second lot pour le niveau suivant

Un traitement par lots effectué pendant la nuit ne suffira pas à atteindre votre objectif de 80 % sur l’ensemble de la base de code. Le soir suivant, lancez une nouvelle passe pour le niveau de modules suivant :Vous pouvez aussi passer des tests unitaires aux tests d’intégration pour les parcours utilisateurs critiques :Deux nuits de sessions parallèles peuvent faire passer une base de code de moins de 50 % de couverture à plus de 80 % — un travail qui prendrait des semaines de travail dédié à un ingénieur.