Skip to main content

Adicionar testes unitários ao seu serviço de pagamentos

Crie um playbook para criação de testes de processamento de pagamentos e peça ao Devin para cobrir fluxos de cobrança, lógica de reembolso e manipuladores de webhook com testes unitários abrangentes.
AuthorCognition
CategoryQualidade de código
FeaturesPlaybooks
1

Crie um playbook de testes específico para pagamentos

Um playbook codifica as convenções de teste da sua equipe para que o Devin escreva testes da mesma forma que seus engenheiros. Código de pagamentos tem preocupações específicas — idempotência, precisão de moeda, novas tentativas do gateway, mocking compatível com PCI — por isso um playbook focado em pagamentos detecta problemas que um playbook genérico deixaria passar.Opção 1: escreva o playbook você mesmo. Vá para Settings > Playbooks > Create playbook e defina seus padrões:Opção 2: deixe o Advanced Devin criar o playbook para você. Descreva suas convenções de teste e o Advanced Devin irá gerar um playbook completo:Depois, adicione seu melhor arquivo de teste existente (por exemplo, src/services/__tests__/UserService.test.ts) como uma entrada de Knowledge para que o Devin tenha um exemplo concreto do estilo da sua equipe.
2

Identificar código de pagamento não testado

Antes de apontar o Devin para arquivos específicos, identifique onde estão as lacunas nos seus módulos de pagamento. Peça ao Devin para executar sua ferramenta de cobertura de testes e destacar os piores casos:Devin executa a suíte de testes em seu terminal, analisa o relatório de cobertura e fornece uma 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

Peça ao Devin que escreva testes para o PaymentService

Inicie uma nova sessão, anexe seu playbook de testes de pagamentos (você verá um indicador azul confirmando que ele está anexado) e diga ao Devin qual módulo deve cobrir:Devin lê o módulo, estuda seus testes existentes para identificar padrões, escreve um arquivo de teste abrangente seguindo seu playbook e o executa:
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 abre um PR com o arquivo de teste e um resumo da cobertura de testes na descrição.
4

Conclua os módulos de pagamento restantes

Revise o primeiro PR. Se a estratégia de mocks ou o estilo de asserção não estiverem ideais, atualize seu playbook antes de executá-lo em mais módulos — uma rodada de feedback evita ter que corrigir o mesmo problema em vários PRs.Depois, vá trabalhando na sua lista de gaps:Para ganhar velocidade, use o Advanced Devin para iniciar sessões em paralelo — uma por módulo de pagamento — todas seguindo o mesmo playbook. Ou agende uma sessão semanal que identifique quaisquer módulos de pagamento que tenham ficado abaixo do seu limite de cobertura e escreva testes para eles automaticamente.