Hardhat vs. Foundry 2026: Tests, Fuzzing und Deployment

Mit der Zeit sammelt ein Smart-Contract-Repository neben den Contracts drei Arten von Code an: Unit- und Integrationstests, Skripte, die die Contracts in jedem Netzwerk deployen und konfigurieren, und den Code, der diese Contracts mit einem Backend oder Frontend in TypeScript verbindet.HardhatundFoundrysind die beiden Tools, mit denen diese Arbeit in EVM-Projekten organisiert wird: Sie kompilieren, führen die Tests aus, starten ein lokales Netzwerk und senden die Deployments, und jedes legt fest, in welcher Sprache die einzelnen Teile geschrieben werden.

Jahrelang lief der Vergleich auf die Sprache der Tests hinaus: JavaScript oder TypeScript bei Hardhat, Solidity bei Foundry. Hardhat 3, im August 2025 veröffentlicht, führt Solidity-Tests aus, die mit denen von Foundry kompatibel sind, und verwendet dieselben Standardwerte für Fuzzing und Invarianten wie Foundry, sodass dieses Kriterium die beiden nicht mehr trennt. Entscheidend ist heute, wo der Rest des Repositorys liegt: Sind Deployment und Integration in TypeScript geschrieben, führt Hardhat sie mit den Tests zusammen; arbeitet das Team mit Solidity-Skripten und über die Kommandozeile, kommt Foundry mit weniger Komponenten aus.

Hardhat 3 und Foundry 1.x im November 2026

Hardhat hat Version 3.0.0 am 13. August 2025 veröffentlicht; die neueste stabile Version zum 8. November 2026 ist3.21.2 vom 29. Oktober. Die 2er-Linie wird auf npm weiterhin unter dem Tag hh2 veröffentlicht (2.29.1 stammt vom August 2026), sodass ein älteres Projekt dort bleiben kann, während es die Migration plant. Laut derÜbersicht der Neuerungen in Hardhat 3wird die Konfiguration deklarativ und muss als ESM-Modul geschrieben werden, die Test-Runner werden zu Plugins (empfohlen wird der für Node.js), die Solidity-Coverage wird mit der Option --coverage ermittelt, und das simulierte Netzwerk unterstützt mehrere Chain-Typen, zunächst Ethereum Mainnet und OP Mainnet.

Foundry hat im Februar 2025 die Version 1.0 erreicht, und seine aktuelle stabile Version ist die1.9.0, vom 2. November 2026; die Nightly-Builds, die täglich im Repository erscheinen, sind Prereleases. Die Aufgabenverteilung im Toolset bleibt unverändert: Forge kompiliert, testet und führt Skripte aus; Cast fragt Netzwerke ab und sendet Transaktionen aus dem Terminal; Anvil startet einen lokalen Node, und Chisel ist ein Solidity-Interpreter.

Dieselben Tests in Solidity, mit denselben Standardwerten

In Hardhat 3 gilt eine Datei als Solidity-Test, wenn sie im Ordner test/ liegt oder innerhalb von contracts/ auf .t.sol endet, und jede Funktion, deren Name mit test beginnt, wird als Testfall ausgeführt. DerLeitfaden für Solidity-Testssieht vor, dass forge-std installiert, von dessen Contract Test geerbt und Cheatcodes wie vm.prank verwendet werden können, und behandelt jede Testfunktion mit Parametern als Fuzzing-Test. Eine mit forge-std geschriebene Suite lässt sich ohne Übersetzung nach TypeScript in Hardhat 3 übernehmen und wird mit hardhat test solidity zusammen mit den Integrationstests desselben Projekts ausgeführt.

Auch die Konfiguration der Kampagnen stimmt überein. Beide Werkzeuge führen 256 Fälle pro Fuzzing-Test aus, 256 Sequenzen pro Invariantengruppe mit jeweils 500 Aufrufen und bis zu 5.000 Versuche, um eine fehlgeschlagene Sequenz auf die kürzeste zu reduzieren, die den Fehler reproduziert. Bei Invariantentests schlägt standardmäßig keines der beiden fehl, wenn ein Aufruf revertiert; bei Fuzzing-Tests schlägt Foundry hingegen fehl, wenn ein Revert in einem anderen Contract als dem Test-Contract auftritt.

Eine Invariantenkampagne, die besteht, ohne die Auszahlung zu testen

Ein hypothetisches Beispiel zeigt das anhand eines Einlagen-Contracts mit zwei Funktionen, deposit und withdraw, und einer buchhalterischen Eigenschaft: Die Summe der Nutzersalden entspricht dem Gesamtbestand des Contracts. Das Team schreibt einen Invariantentest, der diese Funktionen über einen Handler aufruft, einen Zwischen-Contract, der für jeden Aufruf Nutzer und Betrag auswählt. Übergibt der Handler an withdraw einen Zufallsbetrag aus dem gesamten Wertebereich von uint256, ist die Wahrscheinlichkeit, dass dieser den Saldo eines Testnutzers nicht übersteigt, vernachlässigbar, und jede Auszahlung revertiert.

Mit failOnRevert auf false, dem Standardwert in Hardhat 3 und in Foundry, lassen diese Reverts die Kampagne nicht fehlschlagen: Die 256 Sequenzen mit je 500 Aufrufen laufen durch, die Eigenschaft gilt bei jeder Prüfung, und das Ergebnis erscheint grün. Die Eigenschaft gilt, weil sich der Zustand kaum ändert, nicht weil die Auszahlung korrekt geschrieben wäre: Ein Rundungsfehler in withdraw würde nie ausgeführt. Foundry hilft, das zu erkennen, weil es standardmäßig Metriken pro aufgerufener Funktion erfasst (show_metrics) und im Bericht anzeigt, und seinLeitfaden für Invariantentestsempfiehlt, die Eingaben im Handler mit bound() einzugrenzen, statt sie mit vm.assume() zu verwerfen.

Die Korrektur ist in beiden Werkzeugen dieselbe. Der Handler begrenzt den Betrag mit bound() auf den Saldo des gewählten Nutzers, führt einen eigenen Zähler effektiver Aufrufe pro Funktion, und der Test verlangt, dass dieser Zähler ein Minimum überschreitet, bevor die Eigenschaft als geprüft gilt. Erzeugt der Handler nur gültige Aufrufe, macht das Aktivieren von failOnRevert jeden unerwarteten Revert zu einem sichtbaren Fehler. Mit den Standardwerten besteht dieselbe Datei in hardhat test solidity und in forge test, wenn der Handler schlecht konstruiert ist: Das Werkzeug führt die Kampagne aus, entscheidet aber nicht, welchen Teil des Contracts sie tatsächlich prüft.

Was sie unterscheidet: Deployment, Skripte und simulierte Netzwerke

Beim Deployment verfolgen die beiden Werkzeuge unterschiedliche Modelle.Hardhat Ignitionbeschreibt das Deployment als deklaratives Modul in TypeScript, mit den Parametern in einer separaten Datei, und speichert in ignition/deployments/chain-<id> ein Journal mit jeder ausgeführten Aktion. Wird ein unterbrochenes Deployment mit demselben Identifier erneut gestartet, wird es ab dem letzten protokollierten Schritt fortgesetzt, und ein neues Modul kann auf Contracts eines früheren Deployments verweisen.

In Foundry ist das Deployment ein Solidity-Skript, das von Script erbt. Laut seinemDeployment-Leitfadensimuliert forge script die Ausführung gegen den Netzwerkzustand, wenn --broadcast nicht angegeben wird, schreibt die Receipts in den Ordner broadcast/ und unterstützt --resume, um einen unterbrochenen Versand fortzusetzen; seit Version 1.8.4 wird der Wiederaufnahmezustand in einer Datei .recovery.json gespeichert, die bis zum Abschluss aufzubewahren ist. Hinzu kommt Cast, mit dem sich ein Contract lesen, Calldata dekodieren oder eine Transaktion aus dem Terminal senden lässt, ohne ein Skript zu schreiben.

Wie schwer dieser Unterschied wiegt, hängt davon ab, wer danach den Betrieb übernimmt. Pflegt dasselbe Team ein Backend in TypeScript, das die Adressen, ABIs und Parameter jedes Netzwerks benötigt, spart es einen Synchronisationsschritt, wenn diese im Hardhat-Projekt liegen; die auf viem basierende Toolbox von Hardhat 3 integriert Ignition, die Contract-Verifizierung und ein Plugin, das verschlüsselte Schlüssel auf der Festplatte speichert. Liegt der Betrieb dagegen bei einem Protokollteam, das aus dem Terminal deployt, abfragt und korrigiert, bündelt Foundry diese Aufgaben in Binaries, die nicht von Node.js abhängen. Die simulierten Netzwerke mit Chain-Typ in Hardhat 3 sind ein zusätzliches Argument für Projekte, die auf OP Mainnet deployen und diese Umgebung lokal nachbilden wollen.

Beide Werkzeuge in einem Repository pflegen

Vor Hardhat 3 nutzten manche Repositories mit TypeScript-Integration Foundry für die Tests und Hardhat für das Deployment. Mit den kompatiblen Tests in Hardhat 3 ist diese Aufteilung für Solidity-Tests nicht mehr nötig, und das Pflegen beider Werkzeuge hat konkrete Kosten: zwei Compiler- und Optimizer-Konfigurationen, die übereinstimmen müssen, zwei Arten der Abhängigkeitsauflösung und zwei Artefaktordner. Weichen sie bei der solc-Version oder den Optimizer-Einstellungen ab, sind der getestete und der deployte Bytecode nicht identisch, und die Verifizierung des Contracts im Explorer kann fehlschlagen.

Werden beide gepflegt, wird die Entscheidung schriftlich festgehalten: Welches Werkzeug kompiliert die Artefakte, die deployt werden, mit welcher solc-Version und welchen Einstellungen, und welche Prüfung in der Continuous Integration bestätigt, dass beide für die Produktions-Contracts denselben Bytecode erzeugen. Ohne diese Prüfung sagt ein grüner Test in dem einen Werkzeug nichts darüber aus, was das andere deployt.

Hardhat vs. Foundry 2026: Das Deployment entscheidet, nicht die Testsprache

Beide Werkzeuge decken Kompilierung und Testausführung ab, einschließlich Fuzzing- und Invariantentests, und seit Hardhat 3 auf demselben Testformat. Für ein neues Repository passt Hardhat 3, wenn Integrationstests, Deployment und die Nutzung der Contracts bereits in TypeScript liegen; Foundry passt, wenn das Projekt vor allem aus Solidity besteht und aus dem Terminal betrieben wird. Keines von beiden macht aus einer schlecht entworfenen Kampagne einen verlässlichen Test oder ersetzt einSmart-Contract-Audits: Der Fall des Handlers zeigt, dass das Ergebnis davon abhängt, welche Aufrufe tatsächlich ausgeführt werden.

Die veröffentlichten Geschwindigkeitswerte für das eine oder andere Werkzeug werden mit konkreten Projekten, Versionen und Maschinen ermittelt. Ist die Laufzeit der Suite für das Team ein Kriterium, ist nur die eigene Messung aussagekräftig: dasselbe Repository, dieselbe solc-Version und dieselbe Anzahl von Fällen, getrennt nach kalter Kompilierung, Kompilierung mit Cache und Dauer der Kampagnen.

Wir entwickeln und auditierenSmart Contractsauf EVM-Netzwerken, und dasAuditumfasst die Prüfung, was die Invariantentests abdecken. Wenn Sie gerade ein Werkzeug für ein Projekt auswählen,erzählen Sie uns davonwie es deployt wird und wer es betreiben soll, und wir sagen Ihnen, welche Organisation von Tests und Deployment dazu passt.