Kernpunkte
- Hardhat organisiert Entwicklung, Tests und Deployment von EVM-Contracts.
- Skripte und Netzwerkkonfiguration ermöglichen die Vorbereitung reproduzierbarer Deployments.
- Es lässt sich mit Foundry kombinieren, wenn das Projekt unterschiedliche Test-Workflows benötigt.
Was ist Hardhat?
Hardhat organisiert Entwicklung, Tests und Deployment von EVM-Smart-Contracts. Es bündelt Compiler-Konfiguration, Netzwerke und Erweiterungen, damit ein Team denselben Ablauf lokal und in der Continuous Integration wiederholen kann. Sein Nutzen endet nicht beim Kompilieren: Es hilft auch, Code, Artefakte und Deployment-Vorgänge miteinander in Beziehung zu setzen.
Hardhat 3 unterstützt Tests in Solidity und TypeScript, mit Integrationen für Werkzeuge wie Viem oder Ethers. Die Auswahl der Plugins und der Testumgebung muss zur Version des Projekts passen; Anleitungen für Hardhat 2 und 3 sollten nicht vermischt werden.
So funktioniert es
Das Projekt legt Compiler, Abhängigkeiten und Netzwerkkonfiguration fest. Die Tests führen Aufrufe gegen eine simulierte Umgebung aus und prüfen Ergebnisse, Events und Reverts. Ein Fork kann den Zustand eines Netzwerks zu einem bestimmten Block verwenden, sofern der RPC den Zugriff auf die benötigten historischen Daten erlaubt.
Das Deployment lässt sich über Skripte oder Werkzeuge wie Ignition organisieren. In beiden Fällen werden Parameter, Adressen und Verifizierungen aufbewahrt. Die Wiederholung einer administrativen Aufgabe darf nicht versehentlich erneut Vermögenswerte ausgeben oder Berechtigungen übertragen: Die Skripte müssen den Zustand prüfen, bevor sie handeln.
Was Hardhat leistet
Hardhat passt, wenn Smart Contracts mit Diensten und Integrationstests in TypeScript zusammenspielen. So lässt sich eine Emission zusammen mit dem Client prüfen, der die Aufrufe vorbereitet und deren Events dekodiert. Das hilft, Abweichungen zwischen der Schnittstelle, die die Anwendung nutzt, und derjenigen, die der Contract bereitstellt, zu erkennen.
Eine Lieferung kann Tests für Rollen, Pausenbedingungen, Übertragung der Administration und das Verhalten gegenüber fehlschlagenden externen Contracts umfassen. Das Team führt je Netzwerk ein Verzeichnis der verwendeten Versionen. So lässt sich ein Vorfall reproduzieren, ohne von der lokalen Konfiguration derjenigen Person abhängig zu sein, die das ursprüngliche Deployment durchgeführt hat.
Grenzen und Auswahlkriterien
Die lokale Simulation bildet nicht alle Bedingungen eines öffentlichen Netzwerks ab. Ein Fork ist eine Momentaufnahme des Zustands, keine Garantie für die künftige Ausführung. Die Tests müssen durch Prüfungen der Zielumgebung und eine Richtlinie für Schlüssel, Berechtigungen und administrative Transaktionen ergänzt werden.
Die Wahl zwischen Hardhat und Foundry hängt von den Testanforderungen und dem Stack des Teams ab. Beide können koexistieren, wenn sie Versionen und Konfiguration ausdrücklich teilen. Ein Hardhat-Update erfordert die Überprüfung von Plugins, Artefakten und Skriptverhalten sowie die Prüfung, ob das Projekt weiterhin kompiliert.
Auch bekannt als
- Hardhat framework
- Hardhat Network





