¿Prefieres no configurarlo manualmente? Pega un enlace a esta página en una sesión de Devin y pídele que lo configure todo por ti. Un [playbook](/es/product-guides/creating-playbooks) codifica las convenciones de pruebas de tu equipo para que Devin escriba tests como lo hacen tus ingenieros. El código de pagos tiene particularidades propias — idempotencia, precisión de moneda, reintentos de la pasarela de pagos, mocking compatible con PCI — por lo que un playbook específico para pagos detecta problemas que uno genérico pasaría por alto. **Opción 1: Escribe tú mismo el playbook.** Ve a [**Settings > Playbooks > Create playbook**](https://app.devin.ai/settings/playbooks/create?utm_source=docs\&utm_medium=use-case-gallery) y define tus estándares: ```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 ``` **Opción 2: Deja que Devin cree el playbook por ti.** Describe tus convenciones de pruebas y Devin generará un playbook completo: ```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. ``` Luego añade tu mejor archivo de prueba existente (por ejemplo, `src/services/__tests__/UserService.test.ts`) como una entrada de [Knowledge](/es/product-guides/knowledge) para que Devin tenga un ejemplo concreto del estilo de tu equipo. Antes de dirigir a Devin a archivos específicos, identifica dónde están las lagunas en tus módulos de pagos. Pídele a Devin que ejecute tu herramienta de cobertura y destaque los casos más críticos: ```txt Analizar la cobertura del módulo de pagos theme={null} Ejecuta npm test -- --coverage y enumera cada archivo en src/services/ que maneje pagos, facturación o suscripciones con menos del 80% de cobertura de líneas de código. Ordénalos por cobertura ascendente para que pueda ver primero las lagunas más grandes. ``` Devin ejecuta la suite en su terminal, analiza el informe de cobertura y te devuelve una lista priorizada: ``` 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 ``` Inicia una nueva sesión, adjunta tu playbook de pruebas de pagos (verás una pastilla azul confirmando que se ha adjuntado) y dile a Devin qué módulo debe cubrir: ```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 lee el módulo, estudia tus pruebas existentes para identificar patrones, escribe un archivo de pruebas completo siguiendo tu playbook y lo ejecuta: ``` PASS src/services/__tests__/PaymentService.test.ts PaymentService processCharge ✓ cobra a una tarjeta de crédito válida y devuelve un recibo (14ms) ✓ usa centavos enteros para evitar errores de punto flotante (6ms) ✓ rechaza cargos duplicados con la misma clave de idempotencia (5ms) ✓ reintenta hasta 3 veces ante un timeout del gateway de Stripe (18ms) ✓ lanza InsufficientFundsError para tarjetas rechazadas (4ms) issueRefund ✓ reembolsa el monto total de un cargo completado (8ms) ✓ reembolsa un monto parcial en centavos cuando se especifica (6ms) ✓ impide reembolsos que superen el monto del cargo original (3ms) ✓ lanza AlreadyRefundedError en intentos de reembolso duplicados (4ms) handleWebhook ✓ procesa eventos charge.succeeded y actualiza el estado del pedido (7ms) ✓ procesa eventos charge.refunded y acredita al cliente (6ms) ✓ verifica la firma del webhook de Stripe antes de procesar (3ms) ✓ ignora tipos de eventos no reconocidos sin generar error (2ms) Cobertura: 94% líneas | 91% ramas | 100% funciones ``` Devin abre un pull request (PR) que incluye el archivo de prueba y un resumen de la cobertura en la descripción. Revisa el primer PR. Si la estrategia de mocks o el estilo de aserciones no es del todo correcto, actualiza tu playbook antes de ejecutarlo en más módulos: una ronda de comentarios te evita corregir el mismo problema en varios PR. Luego avanza por tu lista de brechas de cobertura: ```txt Cover SubscriptionService theme={null} Escribe pruebas para src/services/SubscriptionService.ts usando el mismo playbook. Céntrate en renewSubscription, cancelTrial y proratePlan. Prueba la lógica de prorrateo usando valores enteros de centavos. Apunta a una cobertura de líneas de al menos un 90 %. ``` Para ir más rápido, pídele a Devin que inicie sesiones en paralelo — una por módulo de pagos — todas siguiendo el mismo playbook. O [programa](/es/product-guides/scheduled-sessions) una sesión semanal que detecte cualquier módulo de pagos que haya caído por debajo de tu umbral de cobertura y genere automáticamente pruebas para ellos.

{title}