Em poucas linhas: o PROBAT é a ferramenta de testes automatizados nativa do tlppCore. Ele executa testes unitários, funcionais e integrados em código TLPP e AdvPL, mede a cobertura de código, guarda o histórico das execuções e exporta resultados para ferramentas de CI/CD. Para a empresa, o efeito é aplicar patches e releases com menos risco de quebrar customizações que sustentam a operação.
Toda empresa que usa o Protheus há alguns anos acumula customizações: regras de preço, validações fiscais, integrações, relatórios. Elas funcionam até o dia em que um patch ou uma release muda algo por baixo. Descobrir isso em produção custa caro. Descobrir em um teste automático, minutos depois da compilação, custa quase nada.
Por que testar customização virou prioridade?
O ritmo de mudanças no Protheus aumentou: novas releases, expedições contínuas, pacotes da Reforma Tributária. Cada atualização exige revalidar o que foi customizado. Feito à mão, esse teste é lento, depende de quem conhece o processo e raramente cobre tudo.
Teste automatizado transforma esse conhecimento em código que roda sempre do mesmo jeito, quantas vezes for preciso.
O que é o PROBAT?
Segundo o TDN, o PROBAT é um conjunto de ferramentas nativas do tlppCore para criar e executar testes em programas TLPP ou AdvPL. Para testar fontes AdvPL, o teste precisa ser escrito em TLPP. A partir do AppServer Harpia 20.3.1.x, ele já é expedido no pacote oficial do tlppCore, no tlpp.rpo.
Uma limitação merece destaque: ele não tem recursos para testes de interface. O foco é a regra de negócio, não a tela.
O que ele entrega para a gestão?
| Recurso | Em termos simples | Valor para o negócio |
|---|---|---|
| Testes unitários, funcionais e integrados | Verifica partes isoladas e fluxos inteiros | Menos erro chegando ao usuário |
| Cobertura de código | Mostra quanto do código os testes executam | Saber onde ainda há risco |
| Histórico em SQLite | Guarda o resultado de cada execução | Comparar versões e provar qualidade |
| Exportação para CI/CD | Resultados em formatos de mercado, como JUnit | Integração com a esteira que a TI já usa |
| Cross Validation | Exige pelo menos um teste por item de uma lista | Nenhuma customização crítica fica sem teste |
| Skip por ambiente | Pula testes conforme sistema, versão ou banco | Uma bateria para vários ambientes |
Como funciona a esteira automatizada?
O AppServer tem uma ferramenta de linha de comando que compila fontes, gera e aplica patches e executa rotinas sem interface. O PROBAT se apoia nela. O exemplo do TDN usa o parâmetro -run com a função tlpp.probat.over.setPlan, disponível a partir do tlppCore 01.04.04, para informar ao PROBAT um plano em etapas: clonar o código, compilar e rodar os testes. Quem envia o plano precisa informar o status de cada etapa.
A TOTVS também publica no GitHub um script básico que compila o projeto e executa o PROBAT em um único comando, além de uma extensão para VS Code que mostra a cobertura e cria testes a partir de modelos.
Os resultados ficam guardados por padrão em SQLite, sem configuração. A partir do AppServer 20.3.1.14 e do tlppCore 01.04.05, podem ir para um banco relacional via DBAccess. Como o histórico fica guardado, é possível unificar várias execuções em um único resultado exportado.
Como garantir que nada fique sem teste?
O Cross Validation resolve um problema comum: a regra crítica que ninguém lembrou de testar. A equipe informa no appserver.ini uma função que devolve a lista de "alvos", como fontes, funções, classes ou módulos. A partir daí, cada alvo precisa ter pelo menos um teste marcado com ele. Se faltar, o PROBAT registra erro na apuração dos resultados.
Para a gestão, isso vira uma política verificável: toda customização da lista tem teste, ou a esteira acusa.
E quando o teste só vale em certo ambiente?
O recurso Skip permite pular um teste conforme o sistema operacional, a versão do tlppCore, a versão ou o nome do AppServer, o banco de dados conectado ou uma função customizada. Os filtros de banco e de função customizada existem a partir do tlppCore 01.04.10. É possível combinar filtros, e todos precisam ser verdadeiros para o teste ser pulado.
Assim, uma mesma bateria serve à homologação e aos ambientes de teste, mesmo com bancos ou sistemas operacionais diferentes.
Lista de verificação para começar
- Listar as customizações mais críticas para faturamento, fiscal, estoque e financeiro.
- Confirmar a versão do AppServer e do tlppCore do ambiente.
- Escrever os primeiros testes em TLPP para as regras de maior risco.
- Configurar o Cross Validation com a lista de customizações críticas.
- Automatizar compilação e testes pela linha de comando ou pelo script da TOTVS.
- Exportar os resultados em JUnit para a ferramenta de CI/CD da equipe.
- Acompanhar a cobertura de código a cada ciclo.
- Rodar a bateria antes de cada patch, expedição contínua ou release.
Perguntas frequentes
Preciso reescrever minhas customizações em TLPP?
Não. O código pode continuar em AdvPL; só o teste precisa ser escrito em TLPP.
O PROBAT substitui o teste do usuário-chave?
Não. Ele não testa interface e não valida a experiência de uso. Ele garante que as regras continuem dando o resultado esperado, o que libera o usuário-chave para validar o processo.
Preciso de banco de dados próprio?
Não. Por padrão, o histórico fica em SQLite, criado automaticamente.
Para levar desta leitura
- O PROBAT é nativo do tlppCore e testa código TLPP e AdvPL.
- Cobertura, histórico e exportação em JUnit tornam a qualidade mensurável.
- O Cross Validation obriga teste para cada customização crítica.
- A esteira automatizada reduz o risco de cada patch e release.
Como a WIP Solutions pode ajudar
Customização sem teste é risco acumulado a cada atualização. A WIP Solutions, Prestador de Serviços Homologado TOTVS, apoia empresas que usam o Protheus no Backoffice e no DMS a priorizar as regras críticas, montar baterias de teste com o PROBAT e encaixá-las no ciclo de atualização. Se você quer atualizar com mais segurança, fale com nosso time.