Skip to main content

Agregar pruebas unitarias a tu servicio de pagos

Crea un playbook para escribir pruebas del procesamiento de pagos y haz que Devin cubra los flujos de cobro, la lógica de reembolsos y los manejadores de webhooks con pruebas unitarias exhaustivas.
AuthorCognition
CategoryCalidad de código
FeaturesPlaybooks
1

Crea un playbook de pruebas específico para pagos

Un playbook 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 y define tus estándares:Opción 2: Deja que Advanced Devin cree el playbook por ti. Describe tus convenciones de pruebas y Advanced Devin generará un playbook completo:Luego añade tu mejor archivo de prueba existente (por ejemplo, src/services/__tests__/UserService.test.ts) como una entrada de Knowledge para que Devin tenga un ejemplo concreto del estilo de tu equipo.
2

Identificar código de pagos sin probar

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: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
3

Pídele a Devin que escriba tests para PaymentService

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: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.
4

Trabaja en los módulos de pago restantes

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:Para ir más rápido, usa Devin avanzado para lanzar sesiones en paralelo — una por módulo de pagos — todas siguiendo el mismo playbook. O programa 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.