Skip to main content
1

Crea un playbook di test specifico per i pagamenti

A playbook codifica le convenzioni di testing del tuo team in modo che Devin scriva i test allo stesso modo dei tuoi ingegneri. Il codice che gestisce i pagamenti presenta esigenze specifiche — idempotenza, precisione delle valute, retry del gateway di pagamento, mocking conforme agli standard PCI — quindi un playbook focalizzato sui pagamenti permette di intercettare problemi che uno generico non coglierebbe.Opzione 1: Scrivi tu stesso il playbook. Vai su Settings > Playbooks > Create playbook e definisci i tuoi standard:Opzione 2: Lascia che Devin crei il playbook per te. Descrivi le tue convenzioni di testing e Devin genererà un playbook completo:Poi aggiungi il tuo miglior file di test esistente (ad es. src/services/__tests__/UserService.test.ts) come voce di Knowledge perché Devin abbia un esempio concreto dello stile del tuo team.
2

Individua il codice di pagamento non testato

Prima di puntare Devin verso file specifici, individua dove si trovano le lacune nei tuoi moduli di pagamento. Chiedi a Devin di eseguire il tuo strumento di coverage e di evidenziare i casi peggiori:Devin esegue la test suite nel proprio terminale, analizza il report di coverage e ti fornisce un elenco ordinato per 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

Fai generare a Devin i test per PaymentService

Avvia una nuova sessione, allega il tuo playbook di test per i pagamenti (vedrai un badge blu che ne conferma l’allegato) e indica a Devin quale modulo deve coprire:Devin legge il modulo, analizza i tuoi test esistenti per individuarne i pattern, scrive un file di test completo seguendo il tuo playbook e lo esegue:
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 apre una PR con il file di test e un riepilogo della copertura dei test nella descrizione.
4

Procedi con i moduli di pagamento rimanenti

Esamina la prima pull request (PR). Se la strategia di mock o lo stile delle asserzioni non sono del tutto corretti, aggiorna il tuo playbook prima di eseguirlo su altri moduli: un solo ciclo di feedback ti evita di correggere lo stesso problema su più PR.Poi prosegui con il tuo elenco di gap:Per andare più veloce, chiedi a Devin di avviare sessioni in parallelo — una per modulo di pagamento — tutte seguendo lo stesso playbook. Oppure programma una sessione settimanale che individui i moduli di pagamento scesi sotto la tua soglia di coverage e generi automaticamente i test per loro.