Hardhat vs Foundry: Mana yang Cocok untuk Tim Anda?

Sampai belum lama ini, jawaban umum untuk pertanyaan ini gampang. Pakai Foundry untuk contract dan testing, simpan Hardhat kalau tim frontend butuh. Sejak Hardhat 3 keluar, jawabannya tidak sesederhana itu lagi, karena Hardhat sekarang juga bisa menjalankan test Solidity di atas runtime berbasis Rust. Dua-duanya bagus. Tapi masing-masing mendorong tim ke kebiasaan kerja yang berbeda, dan itu lebih berpengaruh daripada hasil benchmark mana pun.

Ringkasnya Begini

Testing: TypeScript atau Solidity

Di sinilah perbedaan utamanya. Di proyek Hardhat klasik, test ditulis dengan TypeScript. Anda deploy contract, memanggilnya lewat viem atau ethers, lalu mengecek hasilnya dengan Mocha atau test runner bawaan Node. Rasanya familiar untuk developer web, dan contract diuji dengan cara yang sama seperti nanti dipanggil oleh frontend dApp. Kekurangannya, kodenya ramai. Semua panggilan async, semua angka berupa bigint, dan mengecek satu revert saja butuh beberapa baris.

Test di Foundry adalah contract Solidity. Fungsi bernama testTransfer otomatis dianggap test. Cheatcode seperti vm.prank, vm.warp, vm.deal, dan vm.expectRevert dipakai untuk mengganti pemanggil, memajukan waktu, mengisi saldo akun, dan mengecek error, masing-masing cukup satu baris. Developer yang seharian menulis Solidity biasanya lebih suka cara ini karena tidak perlu ganti bahasa. Auditor juga suka, karena sebagian besar proof-of-concept exploit sekarang dipublikasikan dalam bentuk test Foundry.

Hardhat 3 mendukung test Solidity dengan gaya forge-std yang sama. Jadi unit test bisa ditulis di Solidity, sementara TypeScript dipakai untuk integration test yang melibatkan logika offchain. Pembagian seperti ini masuk akal, dan inilah alasan utama jarak antara kedua tools makin dekat.

Kecepatan

Foundry ditulis dengan Rust dan dari dulu memang cepat. Untuk proyek token dengan beberapa ratus test, forge test biasanya selesai dalam hitungan detik setelah compile pertama, sementara suite serupa di Hardhat 2 dengan Mocha bisa makan satu menit lebih. Hardhat 3 memindahkan eksekusinya ke EDR, yang juga ditulis dengan Rust, dan test Solidity-nya sekarang berjalan di kisaran yang mirip dengan Foundry. Test TypeScript masih lebih lambat karena ada lapisan JavaScript, tapi untuk kebanyakan tim selisihnya sudah tidak cukup jadi alasan untuk pindah.

Fuzzing dan Invariant Testing

Beri parameter pada fungsi test Foundry, dan fungsi itu langsung jadi fuzz test. Forge akan memanggilnya ratusan kali dengan input acak, lalu memperkecil kasus yang gagal sampai contoh paling sederhana. Invariant test lebih jauh lagi. Anda menulis aturan yang harus selalu benar, misalnya jumlah semua saldo sama dengan totalSupply, lalu Foundry memanggil urutan fungsi secara acak lewat kontrak handler untuk mencoba mematahkannya. Test seperti ini sering menemukan bug yang lolos dari test manual, terutama di perhitungan lending dan AMM.

Test Solidity di Hardhat 3 juga mendukung fuzzing. Dari pengalaman kami, Foundry masih unggul untuk invariant testing: setup-nya lebih matang, contohnya lebih banyak di internet, dan lebih gampang disambungkan ke tools seperti Echidna dan Medusa lewat test harness yang sama. Kalau fuzzing jadi bagian inti proses keamanan Anda, Foundry masih pilihan yang lebih aman saat ini.

Mainnet Forking

Kedua tools bisa fork jaringan live di nomor blok tertentu, jadi Anda bisa testing langsung terhadap pool Uniswap, price feed Chainlink, dan saldo token yang sungguhan. Di Hardhat, tambahkan URL forking dan nomor blok di konfigurasi network. Di Foundry, cukup tambahkan --fork-url saat menjalankan test atau panggil vm.createSelectFork di dalam test. Cara kedua ini juga memudahkan testing lintas dua chain dalam satu file. Selalu kunci nomor bloknya. Kalau tidak, test bisa tiba-tiba gagal sendiri karena state berubah, dan RPC provider harus mengambil data baru setiap kali test jalan.

Script Deploy

Hardhat Ignition mendeskripsikan deploy dalam bentuk modul. Anda menulis contract apa saja yang di-deploy dan fungsi apa yang perlu dipanggil, lalu Ignition yang mengatur urutannya, mengirim transaksi, dan mencatat progresnya di journal. Kalau deploy gagal di tengah jalan, tinggal jalankan ulang dan prosesnya lanjut dari titik terakhir. Fitur ini sangat terasa manfaatnya untuk sistem dengan sepuluh contract dan belasan panggilan setup.

Foundry memakai forge script. Script deploy ditulis dalam Solidity, dan semua yang ada di antara vm.startBroadcast dan vm.stopBroadcast akan dikirim sebagai transaksi sungguhan. Script dijalankan sebagai simulasi dulu, lalu dikirim dengan --broadcast dan diverifikasi di Etherscan dengan --verify. Sederhana dan enak dibaca. Melanjutkan deploy yang setengah jalan bisa dengan --resume, tapi Anda perlu lebih banyak berpikir sendiri dibanding pakai Ignition.

Plugin dan Ekosistem

• Hardhat punya banyak plugin, termasuk verifikasi contract, plugin OpenZeppelin Upgrades, dan pengetikan TypeScript otomatis lewat viem. Sistem plugin berubah di Hardhat 3, jadi cek dulu apakah plugin yang Anda pakai sudah mendukung versi 3 sebelum upgrade.
• Foundry sudah membawa sebagian besar tools-nya sendiri. cast untuk membaca dan menulis data chain dari terminal, anvil untuk node lokal, dan chisel untuk mencoba potongan Solidity secara interaktif. OpenZeppelin juga menyediakan library Upgrades versi Foundry.
• Tim frontend biasanya lebih nyaman dengan Hardhat karena tipe contract dan ABI bisa langsung dipakai di dApp TypeScript.
• Peneliti keamanan dan firma audit kebanyakan bekerja di Foundry, sehingga temuan lebih gampang dibagikan dalam bentuk test yang bisa langsung dijalankan.

Memakai Keduanya di Satu Repo

Anda tidak wajib memilih salah satu. Setup yang sering kami pakai menaruh semua contract di satu folder, menjalankan unit test, fuzz test, dan invariant test dengan forge, lalu memakai Hardhat untuk integration test TypeScript dan deploy Ignition yang dikelola tim backend. Kedua tools harus sepakat soal path import, jadi pakai satu file remappings.txt dan samakan versi compiler serta setting optimizer di kedua konfigurasi. Kalau tidak, bytecode yang diuji bisa beda dengan yang di-deploy.

Cara Memilih

1. 1Lihat siapa yang menulis test. Tim yang isinya spesialis Solidity akan lebih cepat di Foundry. Tim full-stack yang sehari-hari menulis TypeScript akan lebih nyaman di Hardhat.
2. 2Cek berapa besar nilai yang disimpan contract. Protokol yang mengelola dana sungguhan butuh fuzz dan invariant test, dan itu mengarah ke Foundry atau setidaknya test bergaya Foundry.
3. 3Hitung kerumitan deploy-nya. Banyak contract dengan setup rumit lebih cocok pakai Ignition. Beberapa contract dengan setup sederhana cukup dengan forge script.
4. 4Periksa plugin dan library yang sudah Anda pakai, dan pastikan semuanya mendukung Hardhat 3.
5. 5Tetapkan satu tool sebagai default untuk pekerjaan baru, tulis di README, dan jangan biarkan setiap developer memilih sendiri.

Tool terbaik adalah tool yang benar-benar dipakai seluruh tim untuk menulis test. Test runner secepat apa pun tidak melindungi apa-apa kalau test-nya tidak ada.

Di pelatihan smart contract dan Ethereum kami, kedua tools ini diajarkan berdampingan. Kami mulai dari Foundry untuk unit test dan fuzz test, lalu menunjukkan posisi Hardhat begitu dApp TypeScript dan pipeline deploy mulai masuk ke proyek.