Tag: Testes Automatizados

É uma satisfação compartilhar o lançamento de um livro escrito por um amigo. Vinicius Sanchez é o autor de Back-end Delphi: Microsserviços com Horse, Docker e Kubernetes, uma obra que se propõe a acompanhar o desenvolvedor desde a criação das primeiras rotas HTTP até a execução de uma plataforma de serviços em Kubernetes. A amizade é uma razão pessoal para trazer essa notícia ao blog; o assunto do livro é o que torna a conversa relevante para quem trabalha com Delphi.

A pergunta que orienta esta apresentação é prática: o que esse percurso pode oferecer a quem já conhece a linguagem e deseja construir aplicações que atendam a outros sistemas? Para respondê-la, vou apresentar a proposta, o projeto usado como fio condutor, os requisitos de estudo e alguns critérios para avaliar se o conteúdo corresponde à sua necessidade.

Esta apresentação se baseia na página oficial do livro e nos materiais públicos de apoio. Não é uma resenha resultante da leitura integral da obra. Essa distinção permite celebrar o lançamento e deixar claro ao leitor o alcance desta análise.

O sistema foi atualizado, os campos da reforma tributária apareceram na tela e uma nota foi autorizada. Isso demonstra que a emissão funcionou naquele cenário, mas ainda deixa uma pergunta importante: a parametrização representa corretamente as operações da empresa? O Portal Nacional da NF-e esclarece o alcance da autorização de uso: ela envolve verificações formais e de regras de conteúdo, sem transferir ao Fisco a responsabilidade pelo mérito da operação declarada. Por isso, contador e desenvolvedor precisam comparar decisões fiscais, dados do cadastro e informações efetivamente geradas.

A revisão proposta acompanha o caminho da decisão fiscal até a emissão: começa pelo preenchimento do cadastro, verifica a coerência dos códigos e o contexto da operação, confere o XML e a vigência das regras e, por fim, reúne as evidências dos testes. Ao longo desse percurso, é preciso distinguir uma rejeição técnica de um enquadramento fiscal inadequado, pois cada problema exige uma investigação diferente.

O blog já explicou por que uma nota autorizada pode estar tributariamente errada. Aqui, vamos transformar o entendimento em seis cenários de revisão do sistema de gestão empresarial, o ERP. O foco é a Nota Fiscal Eletrônica (NF-e), com fontes conferidas em 13 de outubro de 2026. Os testes propostos são procedimentos didáticos; não representam execução em um emissor real nem homologação de integração.

Quem mantém um sistema comercial em Delphi conhece a distância entre receber uma sugestão e entregar uma alteração confiável. Uma configuração precisa corresponder ao ambiente instalado, um documento deve representar os dados corretos e uma correção precisa sobreviver à compilação, aos testes e à operação. A inteligência artificial pode ajudar nesse percurso, mas uma resposta convincente ainda não demonstra que o trabalho foi resolvido.

É com essa preocupação que apresento meu novo livro, ACBr com IA na Prática: Inteligência artificial aplicada ao dia a dia do desenvolvimento com Delphi e ACBr. A proposta é aproximar a IA dos problemas concretos de desenvolvimento, diagnóstico e manutenção, sem transferir a ela a responsabilidade por decisões técnicas ou fiscais. O centro da leitura é um método de trabalho que o desenvolvedor consegue acompanhar, conferir e repetir.

Neste artigo, explico o recorte da obra, o que o leitor encontra nos materiais e como começar a aplicar essa abordagem em uma tarefa pequena. Não é preciso dominar inteligência artificial para entender a proposta. É importante, porém, reconhecer que produtividade não deve ser medida apenas pela quantidade de código produzido ou pela velocidade da primeira resposta.

Conheça o livro ACBr com IA na Prática, consulte o sumário e leia a degustação na página oficial.

Um sistema Delphi em produção raramente é apenas um conjunto de arquivos-fonte. Ele costuma concentrar regras de negócio acumuladas, integrações pouco documentadas, decisões tomadas sob restrições que já não existem e rotinas que funcionam porque foram ajustadas ao longo de muitos anos. Essa realidade pode gerar duas reações igualmente arriscadas: não mexer em nada ou decidir reescrever tudo.

A primeira conserva problemas conhecidos e reduz, aos poucos, a capacidade de adaptação. A segunda troca riscos visíveis por riscos novos: funcionalidades esquecidas, diferenças de comportamento, longos períodos sem entrega relevante e uma convivência difícil entre o sistema antigo e o substituto em construção. Entre esses extremos há uma disciplina de engenharia: modernizar progressivamente, em mudanças pequenas, verificáveis e reversíveis.

Modernizar não significa aplicar tecnologias recentes a qualquer custo. Significa aumentar a capacidade de entender, alterar, testar, entregar e operar o software com menos incerteza. Em um sistema Delphi, isso pode envolver desde tornar a compilação repetível até reduzir o acoplamento entre formulários VCL, regras de negócio e acesso a dados. O ponto de partida não é uma lista de ferramentas; é um diagnóstico honesto do risco.

Conheça o livro e leia uma degustação: acesse a página oficial de Delphi Vivo.

Em 17 de setembro de 2026 participei do episódio “Produtividade Pro: IA na Prática com Delphi, Lazarus e ACBr”, do Papo Pro ACBr. A conversa, com pouco mais de uma hora, passou por ferramentas, código legado, agentes, segurança e formação profissional, mas uma ideia conecta todos esses assuntos: inteligência artificial só produz ganho sustentável quando está inserida em um processo de engenharia que define o trabalho, limita o escopo e verifica o resultado.

Esse ponto merece atenção porque o debate sobre IA costuma começar pela ferramenta ou pelo chamado “prompt perfeito”. Para quem mantém um ERP em Delphi, desenvolve com Lazarus ou integra documentos fiscais por meio do ACBr, porém, o problema real raramente cabe em uma pergunta isolada. Há regras de negócio acumuladas durante anos, dependências visuais, bancos de dados, serviços externos e obrigações fiscais que não admitem uma resposta apenas plausível. Neste artigo, organizo os principais aprendizados do episódio e mostro como convertê-los em um fluxo de adoção prático, com critérios para especificação, validação, segurança e evolução da equipe.

Se sua dificuldade é transformar um pedido à IA em trabalho que possa ser conferido, SDD em Delphi aprofunda especificações, contratos e critérios de aceite ligados a código e testes. Consulte o sumário e a degustação gratuita na página do livro para avaliar essa base de engenharia. Ao longo deste artigo, outras leituras complementam os temas de manutenção e integração, conforme a necessidade.

Desde a versão 2.14, o RadIA passou por uma evolução importante. O foco deixou de estar apenas na expansão do catálogo de ferramentas e avançou para algo mais ambicioso: permitir que o desenvolvedor Delphi compreenda, altere, valide, execute e investigue uma aplicação dentro de um fluxo integrado e verificável.

As versões 2.15.0 e 2.15.1 ampliaram a integração com o código Delphi, fortaleceram a automação de aplicações VCL em execução, melhoraram o processo de diagnóstico e adicionaram novas proteções às interfaces baseadas em WebView2.

Neste artigo, veremos o que mudou e como essas melhorias afetam o uso diário do RadIA.

A versão 2.10 marcou uma mudança importante no RadIA. Foi nela que o projeto ganhou uma camada semântica estrutural própria para Object Pascal, aproximando o agente do código real, dos símbolos, dos tipos, da herança e das interfaces presentes em um projeto Delphi.

Depois dessa fundação, surgiu uma pergunta inevitável: como entregar toda essa capacidade sem exigir que o usuário compreenda a arquitetura interna do produto antes de conseguir utilizá-lo?

O desafio não era remover recursos. Também não era transformar o RadIA em um assistente limitado, capaz apenas de gerar pequenos trechos de código. A proposta sempre foi mais ampla: integrar chat, agente, editor, compilação, testes, debugger, Form Designer, terminal, conhecimento local, MCP, extensões e automações dentro do Delphi.

O verdadeiro desafio era reduzir a carga cognitiva sem reduzir o produto.

Esse foi o eixo principal do trabalho realizado entre as versões 2.10 e 2.12.3. Nesse período, o RadIA ganhou uma jornada inicial mais direta, passou a explicar melhor o que está fazendo, deixou escolhas importantes visíveis, organizou sua presença dentro da IDE e recebeu novos testes de integração para situações que só aparecem quando o software encontra a vida real: uma IDE sem projeto aberto, uma janela acoplada, uma troca rápida entre projetos ou um módulo recriado internamente pela Open Tools API.

Quando falamos sobre qualidade de software, um dos primeiros assuntos que surgem é a criação de testes automatizados. Entretanto, existe uma pergunta que muitas equipes deixam de fazer: os testes realmente estão exercitando as partes mais importantes do sistema?

Em projetos Delphi isso é ainda mais relevante. Grande parte das aplicações corporativas desenvolvidas com a linguagem possui anos de evolução, milhares de linhas de código e regras de negócio extremamente complexas. Sistemas fiscais, ERPs, aplicações financeiras e integrações governamentais normalmente acumulam conhecimento de negócio ao longo de décadas, tornando qualquer alteração um potencial risco.

É justamente nesse cenário que o Code Coverage se torna uma ferramenta valiosa. Ele permite medir quais partes do código foram efetivamente executadas durante os testes automatizados, fornecendo uma visão objetiva sobre o nível de proteção existente no sistema.

Neste artigo veremos o que é cobertura de código, por que ela é importante, como implementá-la em Delphi utilizando o Delphi Code Coverage e o Delphi Code Coverage Wizard Plus, além de entender como integrar os resultados ao SonarQube para acompanhar a qualidade do projeto ao longo do tempo.