Teste de desempenho: o que os testes do CRM não pegaram

Teste de desempenho é medir quanto tempo e quanto recurso o sistema gasta com o volume que vai enfrentar de verdade. No terceiro incremento deste CRM de cobrança, o de pagamentos e baixa, os 182 testes automatizados passaram, e a confirmação de um arquivo de 200 mil pagamentos não terminou em 15 minutos, quando a meta era 2. Depois, um envio de arquivo grande feito pela internet mostrou que, desde o primeiro incremento, nenhum arquivo daquele tamanho passava pelo caminho completo até o sistema. Este artigo mostra os dois problemas, por que os testes não os pegaram e as três lacunas da especificação que só apareceram na implementação.

Os testes passaram#

A especificação dos pagamentos chegou a 22 critérios de aceite, contando os dois que entraram com uma revisão feita durante a implementação (adiante). Cada critério virou um teste que abre um navegador e faz o que o usuário faria, como nos testes de aceitação do incremento anterior. A suíte inteira, com os testes dos três incrementos, ficou com 182 testes, todos passando.

O código foi escrito pelo Claude Code, assistente de programação da Anthropic. Os testes passavam. Pela regra do projeto, faltava ainda a medição de desempenho: a especificação pede que a conferência e a confirmação de 200 mil pagamentos levem até 2 minutos cada, como a importação da carteira.

A medição de 200 mil pagamentos#

A medição roda num ambiente descartável com os mesmos limites de memória e processador da demonstração publicada, com um arquivo fictício de 200 mil pagamentos. O resultado:

A confirmação estava encostada no limite de memória. A causa estava na forma de gravar. A primeira versão montava, dentro do programa, um objeto para cada um dos 200 mil pagamentos, outro para cada título baixado e outro para cada registro de histórico, e só então mandava tudo para o banco de dados. A importação da carteira, feita no primeiro incremento, já resolvia o mesmo problema de outro jeito: o programa calcula o que precisa ser feito e o banco grava tudo em lote, com poucos comandos. A versão corrigida dos pagamentos passou a fazer o mesmo, e a confirmação dos estornos, que tinha o mesmo desenho, foi corrigida junto.

Foi um erro de implementação, e não de especificação: a meta estava escrita, com número. O que faltou foi aplicar ao módulo novo uma solução que o projeto já tinha.

Por que os testes não pegaram#

Os testes de aceitação usam arquivos de poucas linhas. Eles verificam se o sistema faz o que o critério descreve: se o título quitado sai da cobrança, se o pagamento repetido é recusado, se o estorno reabre o título. Com dez pagamentos, a primeira versão fazia tudo isso certo e rápido.

O comportamento e o desempenho são perguntas diferentes, e cada uma exige o seu teste. Um teste de aceitação com 200 mil linhas levaria minutos a cada execução da suíte e ainda não mediria nada, porque roda sem os limites do ambiente real. Por isso a medição é separada, com volume e limites próximos dos reais, e é ela que dá a resposta sobre o tempo.

O caminho completo nunca tinha sido percorrido#

Corrigida a confirmação, faltava conferir que um arquivo grande chegava ao sistema pela internet. Na frente do CRM há um servidor web, que recebe as requisições e as repassa ao sistema, e um filtro de segurança (WAF, de web application firewall) que inspeciona o conteúdo das requisições. O servidor web liberava arquivos de até 50 MB só na tela de importação da carteira. A tela nova, de pagamentos, estava no limite padrão de 1 MB, e um arquivo de 200 mil pagamentos tem cerca de 15 MB.

Ajustado o limite, o envio de teste ainda foi barrado, agora pelo filtro de segurança, que recusa requisições com o corpo acima de um tamanho. A importação da carteira, publicada desde o primeiro incremento, tinha o mesmo problema: um arquivo de 11 MB também era barrado. A especificação promete arquivos de até 50 MB desde o início, e a medição de 200 mil linhas da carteira sempre passou. Só que ela rodava por dentro, direto no sistema, sem passar pelo servidor web nem pelo filtro.

A correção foi uma troca de segurança, e por isso uma decisão minha, não da ferramenta: o filtro deixa de ler o conteúdo só nas três telas de envio de arquivo. Elas exigem login e uma permissão específica, e o bloqueio de endereços maliciosos continua valendo. Depois disso, arquivos de cerca de 190 mil linhas de carteira e de pagamentos chegaram à conferência. Numa empresa, essa decisão passaria pela área de segurança da informação.

Três lacunas que só a implementação mostrou#

Escrever o código obriga a decidir casos que a especificação não previu. Pela regra do projeto, lacuna vira pergunta, e a resposta volta para a especificação antes de virar código, como aconteceu com as lacunas do primeiro incremento.

O devedor que sumia. A lista de devedores mostra quem tem títulos em cobrança. Um devedor que pagou tudo deixava de aparecer, inclusive na busca, e a ficha com o histórico dos pagamentos dele ficava inalcançável pela tela. A decisão: “a busca deve encontrar qualquer devedor”. Sem busca, a lista continua mostrando só quem está em cobrança; com busca, aparece qualquer devedor, marcado como “sem títulos em cobrança”.

O pagamento de um título retirado. Retirado é o título que o credor tirou da carteira em cobrança, sem dizer o motivo. A especificação não dizia o que fazer quando chega um pagamento para ele. A resposta:

Um título retirado que a gente recebe informação de pagamento, a princípio pagamento é mais forte que “retirado” e atualiza. Mas o credor decide isso.

Virou uma política do credor: por padrão, o pagamento é aplicado ao título, que passa a pago se for quitado; a alternativa é o valor virar crédito do devedor, com o título continuando retirado.

O estorno desse pagamento. A decisão anterior abriu outra pergunta. Se o pagamento que quitou um título retirado for estornado, a regra dos estornos devolve o título à cobrança, como faz com qualquer título pago. Mas o credor tinha tirado aquele título da carteira. A resposta foi de novo uma política do credor, com o padrão “em aberto”: o título volta à cobrança e, se não vier no próximo arquivo completo da carteira, é retirado de novo. A alternativa é ele voltar a ser retirado. Esta revisão está na especificação e entra no código depois deste artigo.

As três decisões são de operação e de financeiro. Num projeto comum, a primeira chegaria como reclamação do atendimento (“o cliente pagou e eu não acho a ficha dele”). As outras duas apareceriam na conciliação, com um título cobrado de alguém que já tinha pago ou saído da carteira por outro motivo.

O código aberto, e o que não deveria ter ido junto#

O código do CRM passou a ser público, com licença AGPL-3.0, em github.com/areacli/crm. Cada incremento tem uma branch com o código como ele ficou ao fim do incremento; a deste artigo é incremento-03-pagamentos-e-baixa.

O primeiro envio levou a pasta inteira do projeto: além do código, as especificações, o diário de trabalho e as anotações de operação. A ferramenta tinha perguntado se os detalhes do servidor podiam ficar públicos, mas não o que deveria ir para o repositório, e tratou o repositório como a pasta inteira. A correção veio logo:

No GitHub só deveríamos ter o código da aplicação, o README e a licença.

O repositório foi apagado e recriado só com o código, os arquivos para construir e testar, o README e a licença. O resto continua de onde sai esta série. “O repositório” parecia não precisar de definição. Para quem escreve o código, é a pasta; para quem decide o que o projeto mostra, é só o produto. Numa empresa, essa definição passaria pelo jurídico, por causa da licença e da exposição.

Em números#

O que vem a seguir#

A revisão 4, sobre o estorno de título retirado, entra no código. Depois vem o quarto incremento: o registro dos contatos com o devedor, os acionamentos. A fila de trabalho do operador e os limites de contato continuam em aberto, à espera de decisão.