Ajouter des tests unitaires à votre service de paiement

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.

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.

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

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.

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.