Skip to main content

Fügen Sie Ihrem Payment-Service Unit-Tests hinzu

Erstellen Sie ein Playbook zum Schreiben von Tests für die Zahlungsabwicklung und lassen Sie Devin Zahlungsflüsse, Erstattungslogik und Webhook-Handler mit umfassenden Unit-Tests abdecken.
AuthorCognition
CategoryCodequalität
FeaturesPlaybooks
1

Erstellen Sie ein zahlungsspezifisches Test-Playbook

Ein Playbook hält die Testkonventionen Ihres Teams fest, sodass Devin Tests so schreibt, wie Ihre Engineers es tun. Code für Zahlungsabwicklung hat besondere Anforderungen – Idempotenz, Währungsgenauigkeit, Gateway-Retries, PCI-sicheres Mocking – daher erkennt ein auf Payments fokussiertes Playbook Probleme, die einem generischen entgehen würden.Option 1: Schreiben Sie das Playbook selbst. Öffnen Sie Settings > Playbooks > Create playbook und definieren Sie Ihre Standards:Option 2: Lassen Sie Advanced Devin das Playbook für Sie erstellen. Beschreiben Sie Ihre Testkonventionen, und Advanced Devin generiert ein vollständiges Playbook:Fügen Sie dann Ihre beste bestehende Testdatei (z. B. src/services/__tests__/UserService.test.ts) als Knowledge-Eintrag hinzu, damit Devin ein konkretes Beispiel für den Stil Ihres Teams hat.
2

Nicht getesteten Zahlungscode erkennen

Bevor Sie Devin auf bestimmte Dateien ansetzen, ermitteln Sie, wo die größten Lücken in Ihren Zahlungsmodulen sind. Bitten Sie Devin, Ihr Coverage-Tool auszuführen und Ihnen die größten Problemstellen zu zeigen:Devin führt die Test-Suite in seinem Terminal aus, wertet den Coverage-Bericht aus und liefert Ihnen eine priorisierte Liste:
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

Lassen Sie Devin Tests für PaymentService erstellen

Starte eine neue Session, hänge dein Zahlungs-Test-Playbook an (du siehst einen blauen Pillen-Indikator, der bestätigt, dass es angehängt ist), und sag Devin, welches Modul abgedeckt werden soll:Devin liest das Modul, analysiert deine bestehenden Tests auf Muster, schreibt eine umfassende Testdatei gemäß deinem Playbook und führt sie aus:
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 eröffnet einen Pull Request (PR) mit der Testdatei und einer Zusammenfassung der Testabdeckung im Beschreibungstext.
4

Bearbeiten Sie die restlichen Zahlungsmodule

Überprüfen Sie den ersten Pull Request (PR). Wenn die Mock-Strategie oder der Assertionsstil noch nicht ganz passt, aktualisieren Sie Ihr Playbook, bevor Sie es auf weitere Module anwenden — eine Feedback-Runde erspart Ihnen, denselben Fehler in mehreren PRs korrigieren zu müssen.Arbeiten Sie dann Ihre Lückenliste ab:Um schneller zu sein, verwenden Sie Advanced Devin, um parallele Sitzungen zu starten — eine pro Zahlungsmodul —, die alle demselben Playbook folgen. Oder planen Sie eine wöchentliche Sitzung ein, die alle Zahlungsmodule findet, deren Testabdeckung unter Ihren Schwellenwert gefallen ist, und automatisch Tests dafür schreibt.