Hardhat vs Foundry: qual escolher para o seu projeto em 2026

Durante o desenvolvimento de um contrato inteligente, a equipe precisa compilar o código, testar como ele responde e preparar o deploy. Hardhat e Foundry reúnem ferramentas para esse trabalho, com abordagens diferentes para organizar os testes e conectar o projeto a outras aplicações.

O Hardhat 3 permite trabalhar com testes em Solidity e TypeScript, enquanto o Foundry organiza boa parte do fluxo de testes em torno do Solidity. A escolha depende de como a equipe trabalha e das integrações do projeto. Uma comparação representativa deve incluir permissões, interações entre contratos e cenários de falha.

O que muda com o Hardhat 3

A escolha já não se resume a JavaScript versus Solidity.Hardhat 3permite escrever testes em Solidity e TypeScript, incluindo fuzzing. O Foundry oferece o Forge para compilar, testar e fazer deploy de contratos, o Cast para interagir com redes e o Anvil para desenvolvimento local. A comparação deve indicar as versões e o trabalho que se quer automatizar.

Critérios para escolher

Se o repositório depende de plugins, scripts e serviços TypeScript, avalie quais peças do Hardhat continuam sendo necessárias. Verifique a compatibilidade de cada plugin com a versão escolhida: atualizar o framework não atualiza as extensões automaticamente.

Foundrypermite manter testes e scripts próximos da linguagem dos contratos. Seus testes de invariantes e ferramentas de simulação servem para explorar sequências de operações, além de entradas isoladas. Configurar uma campanha importa tanto quanto dispor do comando: defina atores, limites, estados alcançáveis e propriedades que nunca devem ser violadas.

Não afirmamos que uma ferramenta seja sempre mais rápida. Para decidir, execute o mesmo repositório, compilador, otimizador e número de testes no mesmo ambiente. Separe compilação inicial, cache quente e duração do fuzzing. Publicar um resultado sem essas condições não permite reproduzi-lo.

Um teste de adoção útil

• Compilar os contratos e verificar artefatos reproduzíveis.
• Executar testes unitários, de integração e de invariantes com seeds registradas.
• Simular o deploy e verificar permissões, endereços e configuração por rede.
• Executar o fluxo completo em CI e conservar os logs sem segredos.

O que significa uma campanha encontrar uma falha

Um exemplo de avaliação é um contrato de depósito e saque. Um teste unitário pode verificar um saque específico; uma campanha de invariantes pode explorar diferentes sequências de usuários e operações. Para que a comparação seja útil, as duas configurações devem representar as mesmas regras contábeis e permitir os mesmos estados relevantes.

Se o gerador produz quase sempre chamadas rejeitadas, pode executar muitos testes sem percorrer a lógica que interessa. Revise quais funções e atores participam, quais entradas são descartadas e qual sequência reproduz uma falha. O número de execuções, isoladamente, não permite avaliar a qualidade de uma campanha.

Conserve a configuração e o caso que falha para poder repeti-lo depois de corrigir o contrato. O teste de regressão deve expressar a propriedade violada; trocar a seed até obter um resultado favorável não resolve o problema.

Deploy e manutenção do repositório

Inclua no teste de adoção o caminho de uma compilação limpa até uma rede de teste. Verifique argumentos de inicialização, permissões finais e registro de endereços. Uma equipe pode preferir uma ferramenta porque ela integra melhor esse processo, mesmo que outra conclua antes uma parte dos testes.

Documente a decisão com versões e condições de execução. Se Hardhat e Foundry forem mantidos, atribua a cada um uma responsabilidade específica e certifique-se de que não produzam configurações divergentes. Assim a comparação serve para manter o projeto, não apenas para escolher o primeiro comando de instalação.

Quando combiná-los

Usar ambos pode fazer sentido se cada um cobrir uma necessidade específica da equipe. O custo é manter duas configurações e evitar diferenças de compilador, dependências ou deploy. Essa combinação não deve ser apresentada como prática de todos os auditores nem como garantia de segurança.

Em umprojeto de smart contracts, a decisão deve ficar documentada com testes de aceitação e responsáveis pela operação. A ferramenta ajuda a verificar propriedades; por si só, não demonstra que o contrato esteja correto.