Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.devin.ai/llms.txt

Use this file to discover all available pages before exploring further.

Vous ne souhaitez pas effectuer cette configuration manuellement ? Collez un lien vers cette page dans une session Devin et demandez-lui de tout configurer pour vous.
1

Rédiger un playbook de tests dédié aux paiements

A playbook formalise les conventions de test de votre équipe pour que Devin écrive les tests comme le feraient vos ingénieurs. Le code de paiement présente des contraintes spécifiques — idempotence, précision des montants, réessais de passerelle, mocks conformes au PCI — donc un playbook dédié aux paiements détecte des problèmes qu’un playbook générique manquerait.Option 1 : Rédiger vous‑même le playbook. Allez dans Settings > Playbooks > Create playbook et définissez vos standards de test :Option 2 : Laisser Devin créer le playbook pour vous. Décrivez vos conventions de test et Devin générera un playbook complet :Ajoutez ensuite votre meilleur fichier de test existant (par ex. src/services/__tests__/UserService.test.ts) comme entrée Knowledge pour que Devin dispose d’un exemple concret du style de votre équipe.
2

Identifier le code de paiement non testé

Avant de demander à Devin d’analyser des fichiers spécifiques, identifiez d’abord les lacunes dans vos modules de paiement. Demandez à Devin d’exécuter votre outil de couverture et de mettre en évidence les pires cas :Devin exécute la suite de tests dans son terminal, analyse le rapport de couverture et vous fournit une liste classée par ordre de priorité :
File                                | Lines | Uncovered functions
------------------------------------|-------|------------------------------
src/services/PaymentService.ts      |  34%  | processCharge, issueRefund, handleWebhook
src/services/SubscriptionService.ts |  41%  | renewSubscription, cancelTrial, proratePlan
src/services/InvoiceService.ts      |  52%  | generateInvoice, applyPromoCode, calculateTax
src/services/PayoutService.ts       |  58%  | initiateTransfer, reconcileSettlement
3

Demander à Devin de rédiger des tests pour PaymentService

Démarrez une nouvelle session, joignez votre playbook de tests de paiement (vous verrez une pastille bleue confirmant qu’il est bien joint), et indiquez à Devin quel module couvrir :Devin lit le module, étudie vos tests existants pour en dégager des modèles, écrit un fichier de tests complet en suivant votre playbook, puis l’exécute :
PASS src/services/__tests__/PaymentService.test.ts
  PaymentService
    processCharge
      ✓ charges a valid credit card and returns a receipt (14ms)
      ✓ uses integer cents to avoid floating-point errors (6ms)
      ✓ rejects duplicate charges with the same idempotency key (5ms)
      ✓ retries on Stripe gateway timeout up to 3 times (18ms)
      ✓ throws InsufficientFundsError for declined cards (4ms)
    issueRefund
      ✓ refunds full amount for a completed charge (8ms)
      ✓ refunds partial amount in cents when specified (6ms)
      ✓ prevents refund exceeding the original charge amount (3ms)
      ✓ throws AlreadyRefundedError on duplicate refund attempts (4ms)
    handleWebhook
      ✓ processes charge.succeeded events and updates order status (7ms)
      ✓ processes charge.refunded events and credits the customer (6ms)
      ✓ verifies Stripe webhook signature before processing (3ms)
      ✓ ignores unrecognized event types without error (2ms)

Coverage: 94% lines | 91% branches | 100% functions
Devin ouvre une pull request (PR) avec le fichier de test et un résumé de la couverture de code dans la description.
4

Traitez les modules de paiement restants

Examinez la première PR. Si la stratégie de mock ou le style des assertions n’est pas tout à fait adapté, mettez à jour votre playbook avant de l’exécuter sur davantage de modules — un seul cycle de feedback vous évitera de corriger le même problème sur plusieurs PR.Ensuite, parcourez votre liste de lacunes :Pour aller plus vite, demandez à Devin de lancer des sessions parallèles — une par module de paiement — toutes basées sur le même playbook. Ou planifiez une session hebdomadaire qui détecte automatiquement les modules de paiement passés sous votre seuil de couverture et rédige les tests correspondants.