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. A [playbook](/fr/product-guides/creating-playbooks) 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**](https://app.devin.ai/settings/playbooks/create?utm_source=docs\&utm_medium=use-case-gallery) et définissez vos standards de test : ```txt Payments Test Playbook theme={null} ## Procédure 1. Lire le module de paiement ciblé et identifier toutes les fonctions exportées 2. Étudier les fichiers de test existants dans src/services/__tests__/ pour repérer les schémas récurrents 3. Créer un fichier de test nommé {Module}.test.ts dans __tests__/ à côté de la source 4. Écrire les tests en utilisant le modèle AAA (Arrange, Act, Assert) 5. Mocker le SDK Stripe avec jest.mock('stripe') — ne jamais appeler de véritables APIs de paiement 6. Mocker les appels à la base de données avec les helpers de src/test/helpers.ts 7. Utiliser des entiers en cents pour toutes les valeurs monétaires — jamais de dollars en virgule flottante 8. Tester l’idempotence : appeler processCharge deux fois avec la même clé d’idempotence ne doit pas créer de prélèvements en double 9. Couvrir les cas de succès, d’erreur et les cas limites pour chaque fonction 10. Lancer `npm test -- --coverage` et vérifier au moins 90 % de couverture de lignes pour le fichier ## Spécifications - Framework : Jest avec TypeScript - Mocking : jest.mock() pour le SDK Stripe, jest.spyOn() pour les méthodes internes - Devise : toujours utiliser des entiers en cents (par ex. 2999 et non 29.99) - Assertions : privilégier les matchers spécifiques (toHaveBeenCalledWith, toThrow) - Nommage : describe('PaymentService') > describe('processCharge') > it('charges a valid card') ## Actions interdites - Ne pas appeler Stripe, PayPal ou toute autre passerelle de paiement en production dans les tests - Ne pas utiliser d’arithmétique en virgule flottante pour les calculs monétaires - Ne pas modifier le module source pour le rendre plus facile à tester - Ne pas ignorer les cas limites liés à l’idempotence ou à la logique de réessai ``` **Option 2 : Laisser Devin créer le playbook pour vous.** Décrivez vos conventions de test et Devin générera un playbook complet : ```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. ``` Ajoutez ensuite votre meilleur fichier de test existant (par ex. `src/services/__tests__/UserService.test.ts`) comme entrée [Knowledge](/fr/product-guides/knowledge) pour que Devin dispose d’un exemple concret du style de votre équipe. 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 : ```txt Analyze payment module coverage theme={null} Run npm test -- --coverage and list every file under src/services/ that handles payments, billing, or subscriptions with less than 80% line coverage. Sort by coverage ascending so I can see the biggest gaps first. ``` 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 ``` 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 : ```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 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. 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 : ```txt Cover SubscriptionService theme={null} Write tests for src/services/SubscriptionService.ts using the same playbook. Focus on renewSubscription, cancelTrial, and proratePlan. Test proration math using integer cents. Target 90%+ line coverage. ``` 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](/fr/product-guides/scheduled-sessions) une session hebdomadaire qui détecte automatiquement les modules de paiement passés sous votre seuil de couverture et rédige les tests correspondants.

{title}