Hardhat vs Foundry: cuál elegir para tu proyecto en 2026

Durante el desarrollo de un contrato inteligente, el equipo necesita compilar el código, probar cómo responde y preparar su despliegue. Hardhat y Foundry reúnen herramientas para ese trabajo, con enfoques distintos para organizar las pruebas y conectar el proyecto con otras aplicaciones.

Hardhat 3 permite trabajar con pruebas en Solidity y TypeScript, mientras que Foundry organiza buena parte del flujo de pruebas alrededor de Solidity. La elección depende de cómo trabaja el equipo y de las integraciones del proyecto. Una comparación representativa debe incluir sus permisos, interacciones entre contratos y escenarios de fallo.

Qué cambia con Hardhat 3

La elección ya no se reduce a JavaScript frente a Solidity. Hardhat 3 permite escribir pruebas en Solidity y TypeScript, incluido fuzzing. Foundry ofrece Forge para compilar, probar y desplegar contratos, Cast para interactuar con redes y Anvil para desarrollo local. La comparación debe indicar versiones y el trabajo que se quiere automatizar.

Criterios para elegir

Si el repositorio depende de plugins, scripts y servicios TypeScript, evalúa qué piezas de Hardhat siguen siendo necesarias. Comprueba la compatibilidad de cada plugin con la versión elegida: actualizar el framework no actualiza sus extensiones automáticamente.

Foundry permite mantener pruebas y scripts cerca del lenguaje de los contratos. Sus pruebas de invariantes y herramientas de simulación sirven para explorar secuencias de operaciones, además de entradas aisladas. Configurar una campaña importa tanto como disponer del comando: define actores, límites, estados alcanzables y propiedades que nunca deben romperse.

No afirmamos que una herramienta sea siempre más rápida. Para decidir, ejecuta el mismo repositorio, compilador, optimizador y número de pruebas en el mismo entorno. Separa compilación inicial, caché caliente y duración del fuzzing. Publicar un resultado sin esas condiciones no permite reproducirlo.

Una prueba de adopción útil

• Compilar los contratos y verificar artefactos reproducibles.
• Ejecutar pruebas unitarias, de integración y de invariantes con semillas registradas.
• Simular el despliegue y comprobar permisos, direcciones y configuración por red.
• Ejecutar el flujo completo en CI y conservar logs sin secretos.

Qué significa que una campaña encuentre un fallo

Un ejemplo de evaluación es un contrato de depósito y retirada. Una prueba unitaria puede comprobar una retirada concreta; una campaña de invariantes puede explorar distintas secuencias de usuarios y operaciones. Para que la comparación sea útil, ambas configuraciones deben representar las mismas reglas contables y permitir los mismos estados relevantes.

Si el generador produce casi siempre llamadas rechazadas, puede ejecutar muchas pruebas sin recorrer la lógica que interesa. Revisa qué funciones y actores participan, qué entradas se descartan y qué secuencia reproduce un fallo. El número de ejecuciones aislado no permite valorar la calidad de una campaña.

Conserva la configuración y el caso que falla para poder repetirlo después de corregir el contrato. La prueba de regresión debe expresar la propiedad vulnerada; cambiar la semilla hasta obtener un resultado favorable no resuelve el problema.

Despliegue y mantenimiento del repositorio

Incluye en la prueba de adopción el camino desde una compilación limpia hasta una red de ensayo. Comprueba argumentos de inicialización, permisos finales y registro de direcciones. Un equipo puede preferir una herramienta porque integra mejor ese proceso, aunque otra termine antes una parte de las pruebas.

Documenta la decisión con versiones y condiciones de ejecución. Si se mantienen Hardhat y Foundry, asigna a cada uno una responsabilidad concreta y comprueba que no producen configuraciones divergentes. Así la comparación sirve para mantener el proyecto, no solo para elegir el primer comando de instalación.

Cuándo combinarlos

Usar ambos puede tener sentido si cada uno cubre una necesidad concreta del equipo. El coste es mantener dos configuraciones y evitar diferencias de compilador, dependencias o despliegue. No se debe presentar esa combinación como práctica de todos los auditores ni como garantía de seguridad.

En un proyecto de smart contracts, la decisión debe quedar documentada con pruebas de aceptación y responsables de operación. La herramienta ayuda a comprobar propiedades; no demuestra por sí sola que el contrato sea correcto.