การทดสอบด้วย forge

In Foundry a test file is a Solidity contract that inherits from Test in the forge-std library. Each public function whose name starts with test is run as an individual test case.

Test files live in test/ and conventionally use the .t.sol suffix.

The special setUp() function runs before every test, giving each test a fresh, isolated state. Deploy your contracts and seed any fixtures here.

Because state resets between tests, one test can never accidentally depend on another.

forge-std provides assertion helpers that fail the test with a clear message when they do not hold:

• assertEq(a, b) — equality
• assertTrue(cond) / assertFalse(cond)
• assertGt, assertLt, assertGe, assertLe

Run the whole suite with forge test. Filter by name with --match-test or by contract with --match-contract. Increase verbosity with -v flags to see logs and traces.

Use vm.expectRevert immediately before a call that should fail. The test passes only if the next call reverts, optionally matching a specific error message or custom error.

vm.prank(addr) sets msg.sender for the very next call. vm.startPrank(addr) applies it to all calls until vm.stopPrank(). This lets you test access control without deploying from many keys.

Cheatcodes let you control the environment:

• vm.deal(addr, amount) — set an account's ETH balance
• vm.warp(timestamp) — set block.timestamp
• vm.roll(blockNum) — set block.number

These make time-dependent and balance-dependent logic easy to test deterministically.

vm.expectEmit declares which event fields to check, followed by the expected event, then the call that should emit it. The booleans select which topics and data to match.

vm.label(addr, name) gives addresses readable names in traces. console.log from forge-std prints debug output during tests when run with sufficient verbosity.

Foundry can fork a live network so your tests run against real deployed contracts and state. Set an RPC URL and use vm.createSelectFork to pin a block.

This is invaluable for testing integrations with protocols like Uniswap or Aave without redeploying them.

Good practices for forge tests:

• One behavior per test function
• Descriptive names like testRevertWhenNotOwner
• Shared setup in setUp()
• Use prank for access control, warp for time logic
• Add fork tests for external integrations

You learned forge testing:

• Tests are Solidity contracts inheriting Test; functions start with test
• setUp() gives fresh state per test
• Assertions: assertEq, assertTrue, etc.
• Cheatcodes: prank, deal, warp, expectRevert, expectEmit
• Fork tests run against live network state

Next: fuzzing and invariant testing.