Não quer configurar isso manualmente? Cole um link para esta página em uma sessão do Devin e peça que ele configure tudo para você. A [playbook](/pt-BR/product-guides/creating-playbooks) 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**](https://app.devin.ai/settings/playbooks/create?utm_source=docs\&utm_medium=use-case-gallery) e defina seus padrões: ```txt Playbook de Testes de Pagamentos theme={null} ## Procedimento 1. Leia o módulo de pagamentos alvo e identifique todas as funções exportadas 2. Estude os arquivos de teste existentes em src/services/__tests__/ em busca de padrões 3. Crie um arquivo de teste chamado {Module}.test.ts em __tests__/ ao lado do arquivo fonte 4. Escreva testes usando o padrão AAA (Arrange, Act, Assert) 5. Faça mocking do Stripe SDK com jest.mock('stripe') — nunca chame APIs reais de pagamento 6. Faça mocking das chamadas ao banco de dados com os helpers de src/test/helpers.ts 7. Use valores inteiros em centavos para todas as moedas — nunca valores em ponto flutuante em dólares 8. Teste a idempotência: chamar processCharge duas vezes com a mesma idempotency key não deve criar cobranças duplicadas 9. Cubra caminhos de sucesso, de erro e casos de borda para cada função 10. Execute `npm test -- --coverage` e verifique se o arquivo tem cobertura de linhas de 90% ou mais ## Especificações - Framework: Jest com TypeScript - Mocking: jest.mock() para o Stripe SDK, jest.spyOn() para métodos internos - Moeda: sempre use valores inteiros em centavos (por exemplo, 2999 em vez de 29.99) - Asserções: prefira matchers específicos (toHaveBeenCalledWith, toThrow) - Nomenclatura: describe('PaymentService') > describe('processCharge') > it('charges a valid card') ## Ações proibidas - Não chamar Stripe, PayPal ou qualquer gateway de pagamento real nos testes - Não usar aritmética de ponto flutuante para cálculos de moeda - Não modificar o módulo fonte para facilitar os testes - Não ignorar casos de borda de idempotência ou de lógica de novas tentativas ``` **Opção 2: deixe o Devin criar o playbook para você.** Descreva suas convenções de teste e o Devin irá gerar um playbook completo: ```txt Gere um playbook de testes de pagamentos theme={null} Crie um playbook para escrever testes de unidade para nossos módulos de pagamento em src/services/. Usamos Jest com TypeScript, fazemos mocking do Stripe SDK com jest.mock('stripe') e usamos valores inteiros em centavos para todas as moedas. Confira nossos testes existentes em src/services/__tests__/ para aprender nossos padrões (estilo AAA, matchers específicos, nomenclatura com describe/it). O playbook deve cobrir a estratégia de mocking, testes de idempotência, regras de precisão de moeda e ações proibidas, como chamar APIs reais de pagamento. ``` Depois, adicione seu melhor arquivo de teste existente (por exemplo, `src/services/__tests__/UserService.test.ts`) como uma entrada de [Knowledge](/pt-BR/product-guides/knowledge) para que o Devin tenha um exemplo concreto do estilo da sua equipe. 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: ```txt Analisar cobertura do módulo de pagamentos theme={null} Rode npm test -- --coverage e liste todos os arquivos em src/services/ que lidam com pagamentos, faturamento ou assinaturas com menos de 80% de cobertura de linhas. Ordene por cobertura em ordem crescente para que eu possa ver primeiro as maiores lacunas. ``` 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 ``` 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: ```txt Write tests for PaymentService theme={null} Escreva testes unitários para todas as funções não testadas em src/services/PaymentService.ts. Foque em processCharge, issueRefund e handleWebhook. Cada função precisa de testes para casos de sucesso, erro e casos limite. Faça mock do SDK da Stripe — nunca faça chamadas para APIs reais. Use centavos inteiros para todos os valores monetários. Execute os testes e verifique se há 90%+ de cobertura de linhas para este arquivo. ``` 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. 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: ```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. ``` Para ganhar velocidade, peça ao Devin para iniciar sessões em paralelo — uma por módulo de pagamento — todas seguindo o mesmo playbook. Ou [agende](/pt-BR/product-guides/scheduled-sessions) 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.

{title}