Möchten Sie dies nicht manuell einrichten? Fügen Sie einen Link zu dieser Seite in eine Devin-Sitzung ein und bitten Sie Devin, alles für Sie einzurichten. Ein [Playbook](/de/product-guides/creating-playbooks) 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**](https://app.devin.ai/settings/playbooks/create?utm_source=docs\&utm_medium=use-case-gallery) und definieren Sie Ihre Standards: ```txt Payments Test Playbook theme={null} ## Procedure 1. Read the target payment module and identify all exported functions 2. Study existing test files in src/services/__tests__/ for patterns 3. Create a test file named {Module}.test.ts in __tests__/ next to the source 4. Write tests using the AAA pattern (Arrange, Act, Assert) 5. Mock the Stripe SDK with jest.mock('stripe') — never call real payment APIs 6. Mock database calls with the helpers from src/test/helpers.ts 7. Use integer cents for all currency values — never floating-point dollars 8. Test idempotency: calling processCharge twice with the same idempotency key must not create duplicate charges 9. Cover success paths, error paths, and edge cases for every function 10. Run `npm test -- --coverage` and verify 90%+ line coverage for the file ## Specifications - Framework: Jest with TypeScript - Mocking: jest.mock() for Stripe SDK, jest.spyOn() for internal methods - Currency: Always use integer cents (e.g., 2999 not 29.99) - Assertions: Prefer specific matchers (toHaveBeenCalledWith, toThrow) - Naming: describe('PaymentService') > describe('processCharge') > it('charges a valid card') ## Forbidden Actions - Do not call real Stripe, PayPal, or any live payment gateway in tests - Do not use floating-point arithmetic for currency calculations - Do not modify the source module to make it easier to test - Do not skip idempotency or retry-logic edge cases ``` **Option 2: Lassen Sie Devin das Playbook für Sie erstellen.** Beschreiben Sie Ihre Testkonventionen, und Devin generiert ein vollständiges Playbook: ```txt Generate a payments test playbook theme={null} Create a playbook for writing unit tests for our payment modules in src/services/. We use Jest with TypeScript, mock the Stripe SDK with jest.mock('stripe'), and use integer cents for all currency values. Look at our existing tests in src/services/__tests__/ to learn our patterns (AAA style, specific matchers, describe/it naming). The playbook should cover mocking strategy, idempotency testing, currency precision rules, and forbidden actions like calling real payment APIs. ``` Fügen Sie dann Ihre beste bestehende Testdatei (z. B. `src/services/__tests__/UserService.test.ts`) als [Knowledge](/de/product-guides/knowledge)-Eintrag hinzu, damit Devin ein konkretes Beispiel für den Stil Ihres Teams hat. 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: ```txt Analysiere die Abdeckung des Zahlungsmoduls theme={null} Führe npm test -- --coverage aus und liste jede Datei unter src/services/ auf, die Zahlungen, Abrechnung oder Abonnements verarbeitet und weniger als 80% Zeilenabdeckung hat. Sortiere nach aufsteigender Abdeckung, damit ich die größten Lücken zuerst sehen kann. ``` 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 ``` 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: ```txt Write tests for PaymentService theme={null} Write unit tests for all untested functions in src/services/PaymentService.ts. Focus on processCharge, issueRefund, and handleWebhook. Each function needs tests for success, error, and edge cases. Mock the Stripe SDK — never call real APIs. Use integer cents for all currency values. Run the tests and verify 90%+ line coverage for this file. ``` 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. Ü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: ```txt SubscriptionService abdecken theme={null} Tests für src/services/SubscriptionService.ts mit demselben Playbook schreiben. Fokus auf renewSubscription, cancelTrial und proratePlan. Prorationslogik mit ganzzahligen Cents testen. Ziel: über 90 % Zeilenabdeckung. ``` Um schneller zu sein, bitten Sie Devin, parallele Sitzungen zu starten — eine pro Zahlungsmodul —, die alle demselben Playbook folgen. Oder [planen](/de/product-guides/scheduled-sessions) Sie eine wöchentliche Sitzung ein, die alle Zahlungsmodule findet, deren Testabdeckung unter Ihren Schwellenwert gefallen ist, und automatisch Tests dafür schreibt.

{title}