Recap

What’s up, fellow chain-surfers! 🏄‍♂️

Welcome back to our grand tour of Foundry. So in Part 5 we looked into what Gas is and how it can be optimized to make our contracts user friendly. We wrote a gas-intensive version of an ether batch transfer contract and understood how we can get gas reports and snapshots. Then, we optimized the contract to remove gas intensive parts and used gas saving methods. Finally, we compared the gas used before and after and achieved ~50% reduction.

Please read it if you haven’t already before continuing

Foundry: Zero to Hero - Part 5

Wanna learn Web3 through live and interactive challenges? You’ll love and find that Web3Compass is the best!!

Today’s Outcome

Topic of focus: Time Travel & Events in Tests

Code base - Auction ↗️

We'll be dissecting a simple Auction.sol contract. But the real star of the show isn't the contract itself—it's how we're going to test it. We’re going to become time travelers, bending the blockchain's clock to our will with vm.warp(), and we'll develop advanced hearing to listen for our contract's whispers (aka events) using vm.expectEmit().

Ready to get your hands dirty? Let's dive in!

🧐 Meet Our Specimen: The Auction.sol Contract

First, let's get acquainted with our auction contract. It’s a minimal, no-frills smart contract for a single-item ETH auction.

Here’s our contract - Auction.sol 🚀

Auction State

The contract has several state variables to keep track of everything happening:

• highestBidder (address) & highestBid (uint256): These do exactly what they say on the tin—they track who's currently winning and with how much.

• auctionStartTime & auctionEndTime (uint256): These are immutable timestamps that define the auction's lifespan. Once set in the constructor, they can't be changed.

• seller (address payable): The creator of the auction who will receive the final bid.

• isCanceled & isFinalized (bool): Simple flags to track the auction's status.

• bids (mapping): This is our refund ledger. When someone gets outbid, their bid amount is stored here, waiting for them to withdraw it. This is a crucial part of the "withdraw pattern".

Events & Errors

Our contract is a chatterbox! It emits events for key actions, making it easy for off-chain applications to track what's happening:

• BidPlaced: Fired when a new highest bid is made.

• Withdrawn: Fired when an outbid user withdraws their funds.

• AuctionFinalized: Emitted when the seller finalizes the auction and claims the prize.

• AuctionCanceled: Emitted if the seller cancels the auction.

It also has a bunch of custom errors to give clear feedback when someone tries to do something they shouldn't.

Core Functions

• constructor(uint256 _endTime): When deploying, the seller specifies a duration for the auction. The constructor sets the auctionStartTime to the current block's timestamp and the auctionEndTime to block.timestamp + _endTime.

• bid(): This is where the magic happens. Anyone can call this payable function to place a bid. It checks if the bid is higher than the current highestBid. If it is, it cleverly refunds the previous highest bidder by adding their bid to the bids mapping, then updates highestBidder and highestBid.

• withdraw(): If you've been outbid, you call this function to get your ETH back. It's a pull-based system to prevent nasty re-entrancy bugs.

• finalizeAuction(): Only the seller can call this, and only after the auctionEndTime has passed. It marks the auction as finalized and transfers the highestBid to the seller.

• cancelAuction(): The seller has an escape hatch! They can cancel the auction, but only if no bids have been placed yet.

🧪 Putting It to the Test: Auction.t.sol

Alright, we know the contract. Now, let's see how we can test its every nook and corner with Foundry.

Here’s our test contract - Auction.t.sol 🚀

Our test setup (setUp() function) uses a handy address 0xBEEF as the owner and gives it 10 ETH using vm.deal(owner, 10 ether). We then use vm.prank(owner) to make sure the Auction contract is deployed from this address, setting it as the seller.

Now for the main event!

⏰ Bending Time with vm.warp()

Our contract has time-sensitive logic. The finalizeAuction() function should only work after auctionEndTime. The bid() function should only work before auctionEndTime. How do we test this without sitting around waiting for a day?

We don't! We use vm.warp(). This cheat-code is our time machine; it instantly sets the blockchain's block.timestamp to any value we want.

Let's look at a couple of tests.

First, how do we test that bidding is disabled after the auction ends? Simple:

/// @notice bidding after the auction end time should revert
function testAuctionEnded() public {
    vm.warp(auction.auctionEndTime()); // 1. Fast-forward time!
    vm.expectRevert(Auction.AuctionEnded.selector); // 2. Expect an error
    auction.bid{value: 1 ether}(); // 3. Try to bid
}

In this test, we instantly jump to the auctionEndTime using vm.warp(). At this exact moment, any attempt to bid should fail. We tell Forge to expect the AuctionEnded error, and then we try to bid. If the bid fails with that specific error, the test passes! 🎉

Similarly, to test the happy path for finalizing the auction, we need to be in the future:

function testFinalizeAuction() public {
    // ... users place bids ...

    vm.warp(auction.auctionEndTime()); // Jump to the end

    vm.expectEmit(true, true, true, true);
    emit AuctionFinalized(user2, 2 ether);

    vm.prank(owner);
    auction.finalizeAuction(); // Now, this should work!
}

Without vm.warp(), testing time-dependent logic would be a nightmare. With it, it's a piece of cake.

🎧 Listening for Events with vm.expectEmit()

State changes are great, but a well-behaved contract should also communicate its actions through events. How do we test that the right events are being emitted with the right data? With vm.expectEmit(), of course!

Think of it as putting a stethoscope on your contract. You tell Forge, "I expect to hear this specific sound," and then you trigger the action.

Let's see how we test the BidPlaced event:

/// @notice ensure BidPlaced event is emitted with correct values
function testBid_EmitsBidPlaced() public {
    vm.expectEmit(true, false, false, true); // 1. Set up our listener
    emit BidPlaced(address(this), 1 ether); // 2. Define the expected event

    auction.bid{value: 1 ether}(); // 3. Place the bid
}

Let's break down that vm.expectEmit line, as it can look a bit cryptic: vm.expectEmit(checkTopic1, checkTopic2, checkTopic3, checkData)

• In Solidity events, parameters marked as indexed become topics. They are easier to search for. Non-indexed parameters are part of the data payload.

• OurBidPlaced event is event BidPlaced(address indexed bidder, uint256 amount).

  • bidder is the first topic.

  • amount is the data.

• So, vm.expectEmit(true, false, false, true) means:

  • checkTopic1 = true: Yes, please check the first topic (the bidder's address).

  • checkTopic2 = false: Ignore the second topic (there isn't one).

  • checkTopic3 = false: Ignore the third topic (also doesn't exist).

  • checkData = true: Yes, please check the event's data (the bid amount).

The very next line, emit BidPlaced(address(this), 1 ether);, tells Foundry exactly what to look for: an event where the bidder is the test contract (address(this)) and the amount is 1 ether. When auction.bid() is called, Foundry checks if the emitted event matches these expectations. If it does, we get a green light. ✅

🚀 Wrapping Up

And that's a wrap! We took a seemingly complex Auction contract and wrote powerful, precise tests for it. We saw how to:

• Become a Time Lord with vm.warp() to test logic that depends on the passage of time.

• Become a Super-Listener with vm.expectEmit() to ensure our contract is communicating correctly with the outside world.

• Use other cheat-codes like vm.expectRevert, vm.prank, and vm.deal to create any test scenario we can imagine.

Testing doesn't have to be a chore. With tools like Foundry, it can be an incredibly powerful and, dare I say, fun part of the development process. Now go ahead, clone that repo, run forge test for yourself, and try breaking our contract! Happy forging!

Recap

We’re on a roll! Let’s keep going!

Part 4 we dug deep into writing fuzz and invariant tests. We wrote our token mint contracts and the 1:1 swap contract which let users swap our tokens. Then we fuzz tested our swap by using Foundry’s in-built fuzzer and made sure our contracts fundamental unbreakable rules remained intact in different scenarios using invariant testing.

Please read it if you haven't already before continuing

Foundry: Zero to Hero - Part 4

Wanna learn Web3 through live and interactive challenges? You’ll love and find that Web3Compass is the best!!

Today’s Outcome

Topic of focus: Gas optimization

Code base - BatchTransfer ↗️

• What is Gas and why is it required?

• Create an ether batch transferring contract that’s intentionally gas intensive

• Write tests for getting gas reports and taking gas snapshots

• Optimize our batch transfer contract

• Compare gas consumed before and after

So, What's the Deal with Gas? ⛽

Think of gas as the small fee we pay to get anything done on the Ethereum network. It’s the fuel that makes the whole system run. Every single transaction—from sending tokens to minting an NFT—requires this fuel.

We need gas for two simple reasons:

1. It stops the network from breaking. Without a cost, a single bad piece of code (like an infinite loop) could get stuck and freeze the entire network. Gas acts like a safety switch that cuts the power if a transaction uses too much fuel.

2. It pays the people who run the network. The fees go to validators who use their computers to process our transactions and keep the blockchain secure.

The Biggest Gas Guzzlers to Avoid 💸

Some actions in Solidity barely sip gas, while others chug it like there's no tomorrow. Here are the main ones to watch out for:

1. Writing to Storage (SSTORE)

This is Public Enemy #1 for gas fees. Writing or changing data in storage is like carving something into the blockchain's permanent public record—it's a big deal and very expensive.

• Our goal: Write to storage as little as possible. If we need to use the same piece of stored data multiple times in a function, we should copy it to a memory variable first.

2. Loops (Especially Unpredictable Ones)

A loop that runs over an array in storage can be a ticking time bomb. If that array gets too big, the gas cost to loop through it can become so massive that the function is impossible to call.

• Our goal: Avoid, whenever possible, loops that run based on a storage array that can grow indefinitely.

3. Creating New Contracts (CREATE)

Deploying a new smart contract is a heavyweight operation. It's like adding a new building to the city—a complex and costly process that consumes a lot of gas.

• Our goal: Be mindful of designs where our system needs to create tons of new contracts.

4. External Calls to Other Contracts

When our contract calls another contract, we have to pay the gas for everything that happens inside that other contract, too. It’s like picking up the tab for a friend at a very expensive restaurant.

• Our goal: Be aware of what the contracts we're calling are doing, as their gas costs become our gas costs.

The Solidity Gas Optimization Adventure 🚀

Alright, so we've covered the "what" and "why" of gas. We know it's the fuel and we know that wasting it is like setting a pile of money on fire. 🔥 Now, let's get our hands dirty and dive into the fun part: taking a horribly inefficient smart contract and turning it into a lean, mean, gas-sipping machine.

We'll be using the awesome power of Foundry to not only test our contracts but also to get concrete proof of our heroic optimization efforts. Let's begin!

Meet Our Villain: GassyBatchTransfer.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

// Importing Ownable to add an owner and increase storage reads.
import "@openzeppelin/contracts/access/Ownable.sol";

contract GassyBatchTransfer is Ownable {

    constructor() Ownable(msg.sender) {}

    uint256 public totalTransfersCompleted = 0;
    uint256 public totalEtherSent = 0;


    // A mapping to store data for each recipient.
    mapping(address => uint256) public recipientTransferCounts;

    // A dynamic array in storage. Pushing to this array in a loop is extremely inefficient
    address[] public transferHistory;

    event EtherTransferred(address indexed recipient, uint256 amount);

    // Receives Ether to fund the contract for batch transfers.
    receive() external payable {}

    // Batch transfers Ether to multiple recipients in a highly inefficient way.
    function batchTransfer(address[] memory _recipients, uint256[] memory _amounts) public payable onlyOwner {

        require(_recipients.length == _amounts.length, "Recipients and amounts arrays must have the same length.");
        require(_recipients.length > 0, "No recipients provided.");

        for (uint256 i = 0; i < _recipients.length; i++) {
            address recipient = _recipients[i];
            uint256 amount = _amounts[i];

            // --- Inefficient Check inside the loop ---
            require(recipient != address(0), "Cannot send to the zero address.");

            // Reading from storage (SLOAD) in a loop costs gas every time.
            // We read the owner address here even though it doesn't change and isn't used.
            address contractOwner = owner();
            require(contractOwner != address(0)); // Dummy check to prevent compiler optimization

            payable(recipient).transfer(amount);

            totalTransfersCompleted += 1;
            totalEtherSent += amount;

            // Update the mapping for the recipient.
            recipientTransferCounts[recipient] += 1;

            // Push the recipient to the storage array. This is one of the most
            // gas-intensive operations you can put in a loop.
            transferHistory.push(recipient);

            emit EtherTransferred(recipient, amount);
        }
    }

    // A helper function to check the contract's current balance.
    function getBalance() public view returns (uint256) {
        return address(this).balance;
    }
}

We built this contract with one purpose in mind: to be an absolute gas guzzler. It performs a simple task—sending Ether to a bunch of addresses at once—but it does so in the most spectacularly inefficient way imaginable.

Let's look at its main crimes against gas efficiency:

• The Storage Spree: The biggest issue is inside its for loop. On every single pass, it writes to four different state variables (totalTransfersCompleted, totalEtherSent, recipientTransferCounts, and transferHistory). Think of writing to storage (SSTORE) as carving something into a giant stone tablet. It's permanent, and it takes a ton of energy. Our contract is basically chiseling a new line on that tablet for every single recipient. Ouch.

• Pointless Peeking: Just for good measure, we added address contractOwner = owner(); inside the loop. This reads from storage (SLOAD) every time. It's like re-reading the same sentence over and over again while the meter is running.

• The Ever-Expanding Backpack: The line transferHistory.push(recipient) is a classic gas-trap. Pushing to a dynamic array in storage is like stuffing another item into a backpack that might need to magically grow larger. It's a slow and costly process.

• Data Detour: The function takes its inputs as address[] memory. This tells Solidity to make a copy of all the data in memory. For data we're just reading, this is an unnecessary detour.

The Hero Arrives: OptimizedBatchTransfer.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

contract OptimizedBatchTransfer {

    uint256 public totalTransfersCompleted = 0;
    uint256 public totalEtherSent = 0;
    address public immutable owner;

    constructor() {
        owner = msg.sender;
    }

    // Event to log each transfer. This is an efficient way to log activity.
    event EtherTransferred(address indexed recipient, uint256 amount);

    // Custom error definitions for better error handling and gas efficiency
    error NotOwner();
    error RecipientAndAmountMismatch();
    error NoRecipients();
    error ZeroAddress();
    error InsufficientBalance();

    // Receives Ether to fund the contract for batch transfers.
    receive() external payable {}

    // Batch transfers Ether to multiple recipients in a gas-efficient way.
    function batchTransfer(address[] calldata _recipients, uint256[] calldata _amounts) onlyOwner public payable {

        if (_recipients.length != _amounts.length) revert RecipientAndAmountMismatch();
        if (_recipients.length == 0) revert NoRecipients();

        // We use a local variable to sum up the total amount to be sent.
        // Operations in memory are much cheaper than operations in storage (i.e., updating state variables).
        uint256 totalAmountToSend = 0;
        uint256 recipientsCount = _recipients.length; // Caching array length in a local variable saves gas on each loop access.

        unchecked {
            for (uint256 i = 0; i < recipientsCount; i++) {
                // This check remains inside the loop for security, ensuring no funds are sent to an invalid address.
                if (_recipients[i] == address(0)) revert ZeroAddress();
                // Add the amount to our local sum variable.
                totalAmountToSend += _amounts[i];
            }
        }

        if (address(this).balance < totalAmountToSend) revert InsufficientBalance();

        // We loop again to perform the actual transfers
        for (uint256 i = 0; i < recipientsCount;) {
            payable(_recipients[i]).transfer(_amounts[i]);
            emit EtherTransferred(_recipients[i], _amounts[i]);
            unchecked {
                i++;
            }
        }

        // This is the most critical optimization. We update the state variables only ONCE,
        // after the loop has completed. This saves an enormous amount of gas compared to updating in every iteration.
        unchecked {
            totalTransfersCompleted += recipientsCount;
            totalEtherSent += totalAmountToSend;
        }
    }

    // A helper function to check the contract's current balance.
    function getBalance() onlyOwner public view returns (uint256) {
        return address(this).balance;
    }

    modifier onlyOwner() {
        if (msg.sender != owner) revert NotOwner();
        _;
    }
}

Fear not! We can fix this mess. Our hero contract, OptimizedBatchTransfer.sol, swoops in to save the day (and our Ether). It does the exact same job, but with grace and efficiency.

Here’s how we transformed our villain into a hero:

1. Thinking in Memory: Instead of carving into that stone tablet over and over, we do all our math on a temporary notepad (memory). We create a local variable totalAmountToSend and loop once to add everything up. Memory operations are thousands of times cheaper than storage operations!

2. One Write to Rule Them All: After the loop is done, we update our state variables totalTransfersCompleted and totalEtherSent just once. We went from dozens of expensive storage writes down to two. That's a huge win!

3. Ditching the Baggage: We completely removed the recipientTransferCounts mapping and the transferHistory array. Why? Because we can get the same information almost for free using events. Events are like shouting out a log of what happened for the off-chain world to hear, without needing to permanently store it on that expensive stone tablet.

4. The calldata Express Lane: We changed the function arguments from memory to calldata. Think of calldata as a direct, read-only lane for data coming into our function. It's the most efficient way to handle external inputs that we don't need to change.

5. Speaking in Code: We swapped our require statements for custom errors. Not only does this make our code cleaner, but it also saves a surprising amount of gas compared to using error strings.

The Moment of Truth

Talk is cheap, but gas isn't. Let's get some hard numbers to prove our optimizations worked. This is where Foundry shines.

First let’s make sure we add the following lines to our foundry.toml

gas_reports = ["*"]           # Enable gas reports for all contracts
gas_reports_ignore = []       # Don't ignore any contracts

Gas Reports

let’s writw a simple test in BatchTransfer.t.sol that calls the function for both contracts.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

/// @title Batch Transfer Test
/// @notice This contract tests the gas usage of different batch transfer implementations.
/// Comment the GassyBatchTransfer references and uncomment the OptimizedBatchTransfer references
/// for getting gas reports of OptimizedBatchTransfer contract and vice versa.

import {Test, console} from "forge-std/Test.sol";
import {GassyBatchTransfer} from "../src/GassyBatchTransfer.sol";
//import {OptimizedBatchTransfer} from "../src/OptimizedBatchTransfer.sol";

contract BatchTransferTest is Test {
    GassyBatchTransfer public gassyBatchTransfer;
    //OptimizedBatchTransfer public optimizedBatchTransfer;
    address[] public recipients;
    uint256[] public amounts;
    address public owner;

    uint256 public constant NUM_RECIPIENTS = 10;
    uint256 public constant AMOUNT_PER_RECIPIENT = 10 ether;

    function setUp() public {
        gassyBatchTransfer = new GassyBatchTransfer();
        //optimizedBatchTransfer = new OptimizedBatchTransfer();
        owner = address(this);

        for (uint256 i = 0; i < NUM_RECIPIENTS; i++) {
            // Create new, unique addresses for recipients using Foundry's `makeAddr` cheatcode.
            address recipient = makeAddr(string(abi.encodePacked("recipient", vm.toString(i + 1))));
            recipients.push(recipient);
            amounts.push(AMOUNT_PER_RECIPIENT);
        }

        uint256 totalAmount = AMOUNT_PER_RECIPIENT * NUM_RECIPIENTS;
        vm.deal(address(gassyBatchTransfer), totalAmount);
        //vm.deal(address(optimizedBatchTransfer), totalAmount);

        assertEq(address(gassyBatchTransfer).balance, totalAmount, "Initial balance not correct");
        //assertEq(address(optimizedBatchTransfer).balance, totalAmount, "Initial balance not correct");
    }

    // Add your test functions here
    function test_gas_batchTransfer() public {
        // Test the gas consumption of the batch transfer function
        uint256 gasUsed = gasleft();

        gassyBatchTransfer.batchTransfer(recipients, amounts);
        gasUsed -= gasleft();
        console.log("Gas used for gassy batch transfer:", gasUsed);
        emit log_named_uint("Gas used for gassy batch transfer", gasUsed);

        // optimizedBatchTransfer.batchTransfer(recipients, amounts);
        // gasUsed -= gasleft();
        // console.log("Gas used for optimized batch transfer:", gasUsed);
        // emit log_named_uint("Gas used for optimized batch transfer", gasUsed);
    }
}

First, let’s see the report of out inefficient contract. To see that, we just need to run one command:

Bash

forge test --gas-report

Now we’ll un-comment our optimized contract references, comment our inefficient contract ones and run the same command as above. Foundry will run our tests and spit out a beautiful table. It's like a report card for our functions, showing the average gas cost for each.

When we look at the results, the difference is staggering. The gas cost for GassyBatchTransfer will be ridiculously high, while OptimizedBatchTransfer will be a fraction of the cost. This is the "Aha!" moment where we see just how much Ether we saved.

Gas Snapshots

For an even more granular view, we can use Foundry's snapshot testing. It's like taking a "before" and "after" photo of our gas costs.

Step 1: The "Before" Photo

First, we'll run a snapshot test on our gas-guzzling villain using the BatchTransferSnapshot.t.sol file.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

/// @title Batch Transfer Snapshot Test
/// @notice This contract save the gas snapshots of different batch transfer implementations.
/// Comment the GassyBatchTransfer references and uncomment the OptimizedBatchTransfer references
/// for getting gas snapshots of OptimizedBatchTransfer contract and vice versa.

import {Test, console} from "forge-std/Test.sol";
import {GassyBatchTransfer} from "../src/GassyBatchTransfer.sol";
//import {OptimizedBatchTransfer} from "../src/OptimizedBatchTransfer.sol";

contract BatchTransferSnapshotTest is Test {
    GassyBatchTransfer public gassyBatchTransfer;
    //OptimizedBatchTransfer public optimizedBatchTransfer;
    address[] public recipients;
    uint256[] public amounts;
    address public owner;

    uint256 public constant NUM_RECIPIENTS = 10;
    uint256 public constant AMOUNT_PER_RECIPIENT = 10 ether;

    function setUp() public {
        gassyBatchTransfer = new GassyBatchTransfer();
        //optimizedBatchTransfer = new OptimizedBatchTransfer();

        for (uint256 i = 0; i < NUM_RECIPIENTS; i++) {
            // Create new, unique addresses for recipients using Foundry's `makeAddr` cheatcode.
            address recipient = makeAddr(string(abi.encodePacked("recipient", vm.toString(i + 1))));
            recipients.push(recipient);
            amounts.push(AMOUNT_PER_RECIPIENT);
        }

        uint256 totalAmount = AMOUNT_PER_RECIPIENT * NUM_RECIPIENTS;
        vm.deal(address(gassyBatchTransfer), totalAmount);
        //vm.deal(address(optimizedBatchTransfer), totalAmount);
    }

    // Add your test functions here
    function test_snapshot_batchTransfer() public {

        // Perform the batch transfer
        gassyBatchTransfer.batchTransfer(recipients, amounts);
        //optimizedBatchTransfer.batchTransfer(recipients, amounts);
    }
}

Bash

forge snapshot --match-path test/BatchTransferSnapshot.t.sol

This command runs the test and saves a .gas-snapshot file, which is our "before" picture, detailing the gas usage.

Step 2: The "After" Photo and Comparison

Next, we'll quickly edit our test file to call our optimized hero contract instead, commenting out all our inefficient contract references. Then, we run the snapshot command again, but with a magic flag:

Bash

forge snapshot --diff --match-path test/BatchTransferSnapshot.t.sol

This command runs the test on our optimized code and compares it directly to the "before" photo. The output is pure gold—it will show us the exact percentage of gas we saved. Seeing a number like -49.882% isn't just satisfying; it's proof that we’ve successfully transformed our contract from a gas-guzzling monster into a lean, efficient hero. 🦸‍♂️

And that's a Wrap! (For now 😬)

By now we should have

• Understood what gas is and why it needs to be optimized

• Our gassy and optimized batch transfer contracts

• Tests for getting gas reports for both contracts

• Tests for getting gas snapshots of both contracts

• Understood the optimization we did to achieve the -49.882% gas reduction

What's Next?

Part 6, we'll be

• Writing a simple auction contract where users bid and settle based on time

• Focusing majorly on more advanced tests which helps us simulate time and events

Don't miss it! I'll see you soon! 😎

Recap

Awesome! I see you’re back!

Part 3 was a banger with some good old testing fundamentals. We wrote a pretty simple bank contract through which users could deposit and withdraw funds, as well as check their balances. Deployed the same using anvil and forge and wrote fundamental tests for making sure that all of the functionalities worked as intended

Please read it if you haven't already before continuing

Foundry: Zero to Hero - Part 3

Wanna learn Web3 through live and interactive challenges? You’ll love and find that Web3Compass is the best!!

Today's Outcome

Topic of focus: Fuzz and Invariant Tests

Code base - TokenSwap ↗️

• Write 2 ERC20 token contracts - TokenA and TokenB

• Write a TokenSwap.sol contract to swap our ERC20s

• Let users add liquidity for both tokens in our swap contract

• Let users swap our tokens making sure that there’s enough balance in user’s wallet and our contract pool

• And the most important bit - Write extensive Fuzz and Invariant tests

SHALL WE?!

The What ⁉️

What is Fuzz Testing? 🥴

Fuzz testing is what happens when we give our code an espresso, a blindfold, and a keyboard. It’s an automated technique where we let a "fuzzer" throw absolute nonsense at our functions to see what works (or, more likely, what breaks).

We all have that one test we forget to write. What if the input is 115792089237316195423570985008687907853269984665640564039457584007913129639935? What if it's a negative number in a uint? Instead of losing sleep over it, we let Foundry's fuzzer do our dirty work. We just add parameters to a test function, and Foundry unleashes a relentless barrage of random inputs, hoping to make our code cry. When it fails, the fuzzer proudly presents the input that caused the chaos.

Analogy: Imagine our function is a nightclub bouncer. Normal testing is showing the bouncer a few valid IDs. Fuzz testing is sending a thousand aliens, ghosts, and cartoon characters with crayon-drawn IDs to the front door, just to see if one of them somehow gets in.

What is Invariant Testing? 🏛️

If fuzz testing is poking a single function with a stick, invariant testing is shaking the entire building to see if the foundations are solid.

An invariant is a sacred, unbreakable rule of our contract. It’s a "pinky promise" that must always be true, no matter what happens. For example:

• The total supply of our precious token doesn't just invent itself out of thin air.

• The contract’s piggy bank should never be empty if it still owes people money.

Invariant testing lets Foundry's fuzzer go completely wild on our entire contract. It will call any function it wants, in any order, like a baby who found the TV remote. Its only goal is to break one of our sacred rules. If it manages to shatter a promise, it tells us exactly how it did it, so we can fix our flawed logic.

Analogy: Let's say our contract is a smoothie stall. Our main invariant is: "The number of bananas we have must always equal to the number of bananas we started with, minus the number we've sold." An invariant test is like unleashing a horde of hyperactive squirrels to randomly buy smoothies, sell us more bananas, and try to knock over the stall for a full day. At the end, we check if our banana count is still correct. If not, we've got a squirrelly bug.

The How 🤔

Let’s go ahead and see how we can implement these tests. For this we need to have a contract. Time to implement our Tokens and TokenSwap contracts

Writing the Contracts 📝

TokenA.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract TokenA is ERC20 {
    constructor() ERC20("TokenA", "TKA") {
        _mint(msg.sender, 10000e18);
    }
}

This creates a basic ERC20 token called TokenA using OpenZeppelin’s secure ERC20 implementation.

• Name and Symbol: The token is named "TokenA" and its symbol is "TKA".

• Initial Supply: When the contract is deployed, it mints 10,000 tokens (with 18 decimals) to the deployer’s address.

• ERC20 Standard: By inheriting from OpenZeppelin’s ERC20, TokenA supports all standard ERC20 features like transferring tokens, checking balances, and approving allowances.

Similar to this let’s write TokenB.sol for our TokenB supply

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract TokenB is ERC20 {
    constructor() ERC20("TokenB", "TKB") {
        _mint(msg.sender, 10000e18);
    }
}

OKAYYY!!! There are our token contracts written and ready to be tested. Time to write our swapping contract

TokenSwap.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol"; // Importing the ERC20 interface

contract TokenSwap {
    IERC20 public tokenA; // TokenA contract instance
    IERC20 public tokenB; // TokenB contract instance

    // Constructor to set the token addresses
    constructor(address _tokenA, address _tokenB) {
        tokenA = IERC20(_tokenA);
        tokenB = IERC20(_tokenB);
    }

    // Function to swap TokenA for TokenB
    function swapAforB(uint256 amount) external {
        require(amount > 0, "Amounts must be greater than zero");
        require(tokenA.balanceOf(msg.sender) >= amount, "Insufficient TokenA balance in Wallet");
        require(tokenB.balanceOf(address(this)) >= amount, "Insufficient TokenB balance in Pool");
        tokenA.transferFrom(msg.sender, address(this), amount);
        tokenB.transfer(msg.sender, amount);
    }

    // Function to swap TokenB for TokenA
    function swapBforA(uint256 amount) external {
        require(amount > 0, "Amounts must be greater than zero");
        require(tokenB.balanceOf(msg.sender) >= amount, "Insufficient TokenB balance in Wallet");
        require(tokenA.balanceOf(address(this)) >= amount, "Insufficient TokenA balance in Pool");
        tokenB.transferFrom(msg.sender, address(this), amount);
        tokenA.transfer(msg.sender, amount);
    }

    // Function to add liquidity for TokenA
    function addTokenALiquidity(uint256 amount) external {
        require(amount > 0, "Amount must be greater than zero");
        require(tokenA.balanceOf(msg.sender) >= amount, "Insufficient TokenA balance");
        tokenA.transferFrom(msg.sender, address(this), amount);
    }

    // Function to add liquidity for TokenB
    function addTokenBLiquidity(uint256 amount) external {
        require(amount > 0, "Amount must be greater than zero");
        require(tokenB.balanceOf(msg.sender) >= amount, "Insufficient TokenB balance");
        tokenB.transferFrom(msg.sender, address(this), amount);
    }

}

The contract lets users swap between two ERC20 tokens (TokenA and TokenB) and add liquidity to the pool.

• Token Setup:
  The contract is initialized with the addresses of TokenA and TokenB. It uses the standard ERC20 interface to interact with both tokens.

• Swapping Tokens:

  • swapAforB(amount): Users can swap TokenA for TokenB. The contract checks that the user has enough TokenA and the pool has enough TokenB. It then transfers TokenA from the user to the contract and TokenB from the contract to the user.

  • swapBforA(amount): Users can swap TokenB for TokenA, following the same logic in reverse.

• Adding Liquidity:

  • addTokenALiquidity(amount): Users can deposit TokenA into the pool, increasing the contract’s TokenA balance.

  • addTokenBLiquidity(amount): Users can deposit TokenB into the pool, increasing the contract’s TokenB balance.

• Security Checks:
  Each function checks that the amount is greater than zero and that the sender has enough balance before proceeding.

Fuzz & Invariant Tests 🧪

Our contracts are in place

• TokenA.sol

• TokenB.sol

• TokenSwap.sol

They’re completed and ready to be tested inside and out. No point lollygagging anymore, let’s jump straight into out Fuzz and Invariant test code

TokenSwap.t.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

import "forge-std/Test.sol";

import "../src/TokenSwap.sol";
import "../src/TokenA.sol";
import "../src/TokenB.sol";

contract TokenSwapTest is Test {
    TokenA tokenA;
    TokenB tokenB;
    TokenSwap tokenSwap;

    address user = address(0xABCD); // User address

    /// @dev This function is called before each test
    /// @notice This function sets up the token contracts and initial balances
    function setUp() public {
        tokenA = new TokenA();
        tokenB = new TokenB();
        tokenSwap = new TokenSwap(address(tokenA), address(tokenB));

        // Mint tokens to user and contract for liquidity
        tokenA.transfer(user, 1000e18);
        tokenB.transfer(user, 1000e18);
        tokenB.transfer(address(tokenSwap), 1000e18);
        tokenA.transfer(address(tokenSwap), 1000e18);

        // Approve the TokenSwap contract to spend user tokens
        vm.startPrank(user);
        tokenA.approve(address(tokenSwap), 1000e18);
        tokenB.approve(address(tokenSwap), 1000e18);
        vm.stopPrank();
    }

    /// @dev Fuzz test for addTokenALiquidity
    /// @notice This function tests the addTokenALiquidity function with various input amounts
    function testFuzz_addTokenALiquidity(uint256 amount) public {
        amount = bound(amount, 1, 1000e18); // Bound the amount to a valid range

        // Start test for addTokenALiquidity
        vm.startPrank(user);
        tokenA.approve(address(tokenSwap), amount);
        tokenSwap.addTokenALiquidity(amount);
        // Check liquidity added
        assertEq(tokenA.balanceOf(address(tokenSwap)), 1000e18 + amount);
        assertEq(tokenA.balanceOf(user), 1000e18 - amount);
        vm.stopPrank();
    }

    /// @dev Fuzz test for addTokenBLiquidity
    /// @notice This function tests the addTokenBLiquidity function with various input amounts
    function testFuzz_addTokenBLiquidity(uint256 amount) public {
        amount = bound(amount, 1, 1000e18);

        // Start test for addTokenBLiquidity
        vm.startPrank(user);
        tokenB.approve(address(tokenSwap), amount);
        tokenSwap.addTokenBLiquidity(amount);
        // Check liquidity added
        assertEq(tokenB.balanceOf(address(tokenSwap)), 1000e18 + amount);
        assertEq(tokenB.balanceOf(user), 1000e18 - amount);
        vm.stopPrank();
    }

    /// @dev Fuzz test for swapAforB
    /// @notice This function tests the swapAforB function with various input amounts
    function testFuzz_swapAforB(uint256 amount) public {
        amount = bound(amount, 1, 1000e18);
        vm.assume(tokenA.balanceOf(user) >= amount); // User must have enough TokenA
        vm.assume(tokenB.balanceOf(address(tokenSwap)) >= amount); // TokenSwap must have enough TokenB

        // Start test for swapAforB
        vm.startPrank(user);
        tokenA.approve(address(tokenSwap), amount);
        uint256 userTokenBBefore = tokenB.balanceOf(user);
        uint256 contractTokenBBefore = tokenB.balanceOf(address(tokenSwap));
        tokenSwap.swapAforB(amount);
        // Check balances after swap
        assertEq(tokenA.balanceOf(user), 1000e18 - amount);
        assertEq(tokenB.balanceOf(user), userTokenBBefore + amount);
        assertEq(tokenB.balanceOf(address(tokenSwap)), contractTokenBBefore - amount);
        vm.stopPrank();
    }

    /// @dev Fuzz test for swapBforA
    /// @notice This function tests the swapBforA function with various input amounts
    function testFuzz_swapBforA(uint256 amount) public {
        amount = bound(amount, 1, 1000e18);
        vm.assume(tokenB.balanceOf(user) >= amount);
        vm.assume(tokenA.balanceOf(address(tokenSwap)) >= amount);

        // Start test for swapBforA
        vm.startPrank(user);
        tokenB.approve(address(tokenSwap), amount);
        uint256 userTokenABefore = tokenA.balanceOf(user);
        uint256 contractTokenABefore = tokenA.balanceOf(address(tokenSwap));
        tokenSwap.swapBforA(amount);
        // Check balances after swap
        assertEq(tokenB.balanceOf(user), 1000e18 - amount);
        assertEq(tokenA.balanceOf(user), userTokenABefore + amount);
        assertEq(tokenA.balanceOf(address(tokenSwap)), contractTokenABefore - amount);
        vm.stopPrank();
    }

    // Invariant: total supply of TokenA and TokenB never changes
    /// @notice This function checks that the total supply of both tokens remains constant
    function invariant_totalSupplyConstant() public view {
        assertEq(tokenA.totalSupply(), 10000e18);
        assertEq(tokenB.totalSupply(), 10000e18);
    }

    // Invariant: sum of TokenA balances between user and contract is always <= 10000e18
    /// @notice This function checks that the sum of TokenA balances between user and contract is always <= 10000e18
    function invariant_tokenABalanceSum() public view {
        uint256 sum = tokenA.balanceOf(user) + tokenA.balanceOf(address(tokenSwap));
        assertLe(sum, 10000e18);
    }

    // Invariant: sum of TokenB balances between user and contract is always <= 10000e18
    /// @notice This function checks that the sum of TokenB balances between user and contract is always <= 10000e18
    function invariant_tokenBBalanceSum() public view {
        uint256 sum = tokenB.balanceOf(user) + tokenB.balanceOf(address(tokenSwap));
        assertLe(sum, 10000e18);
    }
}

Here the test contract rigorously checks the behavior of the TokenSwap smart contract. Here’s what it does:

• Setup:
  Before each test, it deploys fresh instances of TokenA, TokenB, and TokenSwap. It gives both the user and the TokenSwap contract 1,000 tokens each for liquidity and sets up the necessary approvals.

• Fuzz Tests:
  These tests use random amounts to check the swap and liquidity functions:

  • testFuzz_addTokenALiquidity and testFuzz_addTokenBLiquidity verify that users can add liquidity in various amounts and that balances update correctly.

  • testFuzz_swapAforB and testFuzz_swapBforA check that swapping tokens works for any valid amount, ensuring balances change as expected.

• Invariant Tests:
  These tests ensure that certain properties always hold, no matter what sequence of actions is performed:

  • invariant_totalSupplyConstant checks that the total supply of both tokens never changes.

  • invariant_tokenABalanceSum and invariant_tokenBBalanceSum ensure that the sum of user and contract balances for each token never exceeds the original supply.

• Testing Tools:
  The contract uses Foundry’s vm.startPrank to simulate actions from the user’s address and bound to keep fuzzed amounts within a valid range.

ANDDD, let’s test! Use forge to start testing our swap contract

forge coverage

There we have our test results. BOO YAA!! Amazing work!

We can do this to any type of contract and make sure our contracts are bullet proof. Maybe try writing a token Borrowing contract and hit it with Fuzz and Invariant tests. It’s always great to learn by doing. We now have the power of testing contracts rigorously, and like someone wise once told

And that's a Wrap! (For now 😬)

By now we should have

• Our token and swap contracts written

• Can add liquidity to our swap contract and swap our tokens

• We have written proper & extensive Fuzz and Invariant tests for it

• Checked our test coverage and got close to 100%

What's Next?

Part 5, we'll be

• Writing a batch token sender contract

• Focusing majorly on getting Gas reports and optimizations

Don't miss it! I'll see you soon! 😎

Recap

Welcome back folks! Part 2 took us through some pretty good stuff. We learnt how to use anvil to run a local simulation of a blockchain in our systems. Then we used a simple forge command to deploy our contract to our local chain. And finally used cast to interact with our deployed contract

Please read it if you haven't already before continuing

Foundry: Zero to Hero - Part 2

Learn Web3 through live and interactive challenges at Web3Compass

Today's Outcome

Topic of focus: Testing fundamentals

• Write a SimpleBank.sol contract

• Let users deposit & withdraw funds

• Use function modifiers to restrict access to only owner of the deployed contract

• And the most important bit - Write extensive tests for it!

SHALL WE?!

📝 Writing the Contract

By now we know how to initiatize our project using forge. So, let’s jump right into the contract code

Here’s the SimpleBank.sol contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

// Simple bank contract that allows users to deposit, withdraw, and check their balances.
contract SimpleBank {
    address public owner; // Owner of the contract
    mapping(address => uint256) private balances; // Mapping of user addresses to their balances

    constructor(address _owner) {
        owner = _owner;
    }

    // Set owner
    function setOwner(address newOwner) onlyOwner public {
        owner = newOwner;
    }

    // Deposit Ether into the bank
    function deposit() public payable {
        require(msg.value > 0, "Deposit amount must be greater than zero");
        balances[msg.sender] += msg.value;
    }

    // Withdraw Ether from the bank, only owner can call
    function withdraw(uint256 amount) onlyOwner public {
        require(balances[owner] >= amount, "Insufficient balance");
        balances[owner] -= amount;
        payable(owner).transfer(amount);
    }

    // Get the balance of the owner
    function getBalance() onlyOwner public view returns (uint256) {
        return balances[owner];
    }

    // Modifier to restrict access to the owner
    modifier onlyOwner() {
        require(msg.sender == owner, "Not the contract owner");
        _;
    }
}

SimpleBank Contract Explained

Our contract lets a single owner safely deposit and withdraw Ether. Here’s how it works:

• Owner: The contract is created with an owner address. Only this owner can withdraw funds or check the balance.

• Deposit: Anyone can deposit Ether by calling the deposit() function. The contract keeps track of how much Ether each address has deposited.

• Withdraw: Only the owner can withdraw Ether using the withdraw() function. The contract checks that the owner has enough balance before allowing the withdrawal.

• Check Balance: The owner can check their balance with the getBalance() function.

• Change Owner: The owner can transfer ownership to another address using setOwner().

• Security: The onlyOwner modifier makes sure that only the owner can perform sensitive actions like withdrawing or checking the balance.

Time to test!!

🧪 Testing the Contract

Let’s extensively test our SimpleBank.sol contract.

SimpleBank.t.sol test file

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30;

import {Test, console} from "forge-std/Test.sol";
import {SimpleBank} from "../src/SimpleBank.sol";

contract SimpleBankTest is Test {
    SimpleBank public bank;

    // Set up the contract
    function setUp() public {
        bank = new SimpleBank(msg.sender);
    }

    // Test setting a new owner
    function testSetOwnerByOwner() public {
        vm.startPrank(bank.owner());
        bank.setOwner(address(0));
        assertEq(bank.owner(), address(0));
        vm.stopPrank();
    }

    // Test setting a new owner by non-owner
    function testSetOwnerByNonOwner() public {
        vm.expectRevert("Not the contract owner");
        bank.setOwner(address(0));
    }

    // Test deposit by owner
    function testDepositByOwner() public {
        vm.startPrank(bank.owner());
        uint256 initialBalance = bank.getBalance();
        bank.deposit{value: 1 ether}();
        uint256 newBalance = bank.getBalance();
        assertEq(newBalance, initialBalance + 1 ether);
        vm.stopPrank();
    }

    // Test deposit by non-owner
    function testDepositByNonOwner() public {
        vm.prank(bank.owner());
        uint256 initialBalance = 0;
        bank.deposit{value: 1 ether}();
        vm.prank(bank.owner());
        uint256 newBalance = bank.getBalance();
        assertEq(newBalance, initialBalance + 1 ether);
    }

    // Test withdraw by owner
    function testWithdrawByOwner() public {
        vm.startPrank(bank.owner());
        bank.deposit{value: 1 ether}();
        uint256 initialBalance = bank.getBalance();
        bank.withdraw(0.5 ether);
        uint256 newBalance = bank.getBalance();
        assertEq(newBalance, initialBalance - 0.5 ether);
        vm.stopPrank();
    }

    // Test withdraw with insufficient balance
    function testWithdrawNoBalance() public {
        vm.startPrank(bank.owner());
        bank.deposit{value: 1 ether}();
        vm.expectRevert("Insufficient balance");
        bank.withdraw(2 ether);
        vm.stopPrank();
    }

    // Test withdraw by non-owner
    function testWithdrawByNonOwner() public {
        bank.deposit{value: 1 ether}();
        vm.expectRevert("Not the contract owner");
        bank.withdraw(0.5 ether);
    }

    // Test get balance by owner
    function testGetBalanceByOwner() public {
        vm.startPrank(bank.owner());
        bank.deposit{value: 1 ether}();
        uint256 balance = bank.getBalance();
        assertEq(balance, 1 ether);
        vm.stopPrank();
    }

    // Test get balance by non-owner
    function testGetBalanceByNonOwner() public {
        vm.expectRevert("Not the contract owner");
        bank.getBalance();
    }

    // Fuzz test for withdraw
    function testFuzz_Withdraw(uint8 amount) public {
        vm.startPrank(bank.owner());
        bank.deposit{value: 10000 ether}();
        uint256 initialBalance = bank.getBalance();
        bank.withdraw(amount);
        uint256 newBalance = bank.getBalance();
        assertEq(newBalance, initialBalance - amount);
        vm.stopPrank();
    }
}

SimpleBankTest Explained

Our test contract checks that the SimpleBank.sol smart contract works as expected. Here’s what each part does:

• Setup: Before each test, a new bank is created with the test contract as the owner.

• Owner Functions: Tests that only the owner can change ownership, withdraw funds, and check the balance. If anyone else tries, the contract should revert with an error.

• Deposits: Checks that both the owner and other users can deposit Ether, and that the balance updates correctly.

• Withdrawals: Verifies that the owner can withdraw funds, but not more than their balance. Also checks that non-owners cannot withdraw.

• Balance Checks: Ensures only the owner can see their balance.

• Fuzz Testing: Randomly tests withdrawals with different amounts to make sure the contract handles all cases safely.

Now, instead of running the forge test command, let’s try something else. Try running

forge coverage

We’ll see that the tests all run correctly, but we also see a coverage report of the entire test suite

Coverage measures how much of our smart contract code is actually tested by our test suite. It shows which lines of code were executed during testing and which lines were missed.

• Why is it useful?
  High coverage means our tests are checking most parts of your contract, making it less likely that bugs or vulnerabilities go unnoticed.

• How do we check coverage?
  In Foundry, we can run forge coverage to see a report. This report highlights which functions and lines were tested and gives us a percentage score.

• What should we aim for?
  Aim for as close to 100% coverage as possible, but remember: coverage alone doesn’t guarantee your contract is bug-free. Good tests and thoughtful scenarios are just as important.

And that's a Wrap! (For now 😬)

By now we should have

• Our SimpleBank.sol contract written

• We have written proper & extensive tests for it

• Checked our test coverage and got close to 100%

What's Next?

Part 4, we'll be

• Writing a 1:1 token swap contract

• Focusing majorly on writing Fuzz and Invariant tests for it

Don't miss it! I'll see you soon! 😎

Recap

In the last part, we saw how to setup Foundry in our systems. We created a simple Counter contract project, compiled it and tested it all using the forge command

Please read it if you haven't already before continuing

Foundry: Zero to Hero - Part 1

Learn Web3 through live and interactive challenges at Web3Compass

Today's Outcome

Tool of focus: anvil & cast

• Write a Greeting.sol contract

• Compile & Test it using forge

• Simulate a local blockchain using anvil

• Deploy to the local blockchain using forge

• Interact with the deployed contract using cast

Alright, let's dive in!

🛠️ Building the Contract

In a new folder let's use the forge command to initialize our Greeting contract project

forge init Greeting

We'll now have a folder named Greeting with all the necessary project files.

📝 Writing the Contract

Inside the src folder we'll see that the contract file is corresponding to the Counter contract. This will always be the case when we initialize a new project using forge.

Let's go ahead and change it to our Greeting contract

Greeting.sol Contract

The contract let's us set a state variable to whatever greeting message we desire and retrieve the stored message through a function call

🧪 Compile & Test the Contract

Let's do the same with test folder

Greeting.t.sol Test File

To compile and test the contract, let's go ahead and run the command

forge test

Our Greeting.sol contract is now compiled and tested, ready to be Deployed!

🚀 Deploying the Contract

Deploying our contract is a two step process

• Use anvil to simulate a local blockchain

• Deploy to it using an account anvil provides

Spinning up a local blockchain

All we have to do here is spin up a new instance of terminal and run the command

anvil

Now, we have a local blockchain running in our system with sample wallets to do transactions from

 anvil


                             _   _
                            (_) | |
      __ _   _ __   __   __  _  | |
     / _` | | '_ \  \ \ / / | | | |
    | (_| | | | | |  \ V /  | | | |
     \__,_| |_| |_|   \_/   |_| |_|

    1.2.3-stable (a813a2cee7 2025-06-08T15:42:40.147013149Z)
    https://github.com/foundry-rs/foundry

Available Accounts
==================

(0) 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 (10000.000000000000000000 ETH)
(1) 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 (10000.000000000000000000 ETH)
(2) 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC (10000.000000000000000000 ETH)
(3) 0x90F79bf6EB2c4f870365E785982E1f101E93b906 (10000.000000000000000000 ETH)
(4) 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 (10000.000000000000000000 ETH)
(5) 0x9965507D1a55bcC2695C58ba16FB37d819B0A4dc (10000.000000000000000000 ETH)
(6) 0x976EA74026E726554dB657fA54763abd0C3a0aa9 (10000.000000000000000000 ETH)
(7) 0x14dC79964da2C08b23698B3D3cc7Ca32193d9955 (10000.000000000000000000 ETH)
(8) 0x23618e81E3f5cdF7f54C3d65f7FBc0aBf5B21E8f (10000.000000000000000000 ETH)
(9) 0xa0Ee7A142d267C1f36714E4a8F75612F20a79720 (10000.000000000000000000 ETH)

Private Keys
==================

(0) 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80
(1) 0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d
(2) 0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a
(3) 0x7c852118294e51e653712a81e05800f419141751be58f605c371e15141b007a6
(4) 0x47e179ec197488593b187f80a00eb0da91f1b9d0b13f8733639f19c30a34926a
(5) 0x8b3a350cf5c34c9194ca85829a2df0ec3153be0318b5e2d3348e872092edffba
(6) 0x92db14e403b83dfe3df233f83dfa3a0d7096f21ca9b0d6d6b8d88b2b4ec1564e
(7) 0x4bbbf85ce3377467afe5d46f804f221813b2bb87f24d81f60f1fcdbf7cbf4356
(8) 0xdbda1821b80551c9d65939329250298aa3472ba22feea921c0cf5d620ea67b97
(9) 0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6

Wallet
==================
Mnemonic:          test test test test test test test test test test test junk
Derivation path:   m/44'/60'/0'/0/


Chain ID
==================

31337

Base Fee
==================

1000000000

Gas Limit
==================

30000000

Genesis Timestamp
==================

1754829094

Genesis Number
==================

0

Listening on 127.0.0.1:8545

Let's Deploy

With our local blockchain running and providing us dummy wallets with test ETH, only think left to do is deploy out contract to it

Each deployment is considered as a transaction on the blockchain. And for a transaction to happen it needs to be initiated from an address in the blockchain. Hence, we need to use a wallet's Private Key provided by anvil in the previous step

Cool, let's deploy

forge create Greeting --interactive --broadcast

• forge create - initiates the deployment

• --interactive - opens interactive mode to enter wallet private key

• --broadcast - broadcasts the deployment transaction across the chain

Okay, we have the address of the wallet from which the contract was deployed, the deployed contract address and the associated transaction hash!

AANDDD... DEPLOYED!!!

💻 Interacting with the Contract

Awesome! Great getting this far! :clap:

When it comes to interacting with our deployed contract, cast is our friend

Set our Greeting Message

Let's see the cast command to do this

cast send <Deployed Contract Address> "setGreeting(string)" "Hello from cast!" --private-key <wallet private key> --rpc-url http://127.0.0.1:8545/

Let's break it down

• cast send - send a transaction

• - in my case it's 0x5FbDB2315678afecb367f032d93F642f64180aa3

• The name of the function to call along with any return types and arguments it has

• --private-key - follow this option with a wallet private key

• --rpc-url - http://127.0.0.1:8545/, the default url to which anvil deploys

Your greeting state variable should now be updated with the value "Hello from cast!". But, let's see for ourselves and not just assume

Get our Greeting Message

The function to get the greeting message is a view only function. This means we are only reading from the state variable and doesn't need to initiate a transaction to do this

Here's the cast command

cast call <Deployed Contract Address> "goGreet() returns (string)" -- --abi-decode

Let's break it down

• cast call - calls a function without broadcasting as a transaction

• - in my case it's 0x5FbDB2315678afecb367f032d93F642f64180aa3

• The name of the function to call along with any return types and arguments it has

• -- --abi-decode - (IMPORTANT)The response we get while calling the function will be in hex. This flag helps decode it to a readable string

Read more about ABIs here

This should return "Hello from cast!".

If that's the case, well my friend, CONGRATULATIONS are in order!! 🎉 🎊

And that's a Wrap! (For now 😬)

By now we should have

• Our Greeting.sol contract compiled, tested

• anvil running a local blockchain

• Greeting.sol deployed to our local blockchain

• Used cast to interact with the deployed contract

What's Next?

Part 3, we'll be

• Writing a simple bank contract

• Focusing majorly on writing proper tests for the logic while handling all edge cases

Don't miss it! I'll see you soon! 😎

Get ready to sweat it out in style while you Forge some piping hot Smart Contracts with molten, smoldering Solidity inside blockchain Foundry

This article is the first of many in which we'll dive deep into building, testing and deploying Smart Contracts using Foundry. We'll also see how to use Foundry to interact with the deployed Smart Contracts.

One article per day and by the end of the series you would be able to use Foundry like a PRO

LFG! 🚀

Today's Outcome

• What's Foundry?

• Install Foundry on our systems

• Build and Test a basic Counter contract

Foundry, What!? 😯

Imagine a beautiful Saturday night - you have a wondrous steak simmering on your pan, ready and staring back at you. What do you do next? Do you just leave it there like that? Do you just walk away? That would be ludicrous!

Steaks, Me like - Spice Boo

You'll get the steak out and slice it, taste test it(I know you're drooling!), transfer the slices to a plate and use cutlery to consume that beauty!

Congratulations! You've become the Foundry of Steaks!

Enter Foundry

OOOKAYY!! - this is exactly what Foundry does for your Smart Contracts

• You have your Smart Contract simmering in your IDE

• Foundry lets you taste "Test" it

• Helps you "Deploy" it to your blockchain plate, and

• Finally let's you "Interact" with the plated Smart Contract

BOOM! Everything you need in ONE SINGLE PACKAGE! And everything written in pure Solidity, no JS/TS!

Enough about steaks, let's start forging

Foundry, How? 🔨

Let's look at how we can setup Foundry in our systems. But, before we do that let's make sure our systems are prepped for installing Foundry

📦 Prerequisite

Rust compiler and Cargo - The easiest way to install them is to go to rustup.rs and follow the steps.

On Windows:

Make sure you have a recent version of Visual Studio with the "Desktop Development with C++" workload installed.

🛠️ Install Foundry

Foundryup is the official installer for the Foundry toolchain. 📘 Learn more here

• Install Foundryup

curl -L https://foundry.paradigm.xyz | bash

This will install the foundryup command in your CLI

• Follow this up with running the command

foundryup

This will automatically install the latest stable versions of forge, cast, anvil and chisel. Each of these have it's own role to play. We'll get to each of them as we progress in the series

👨‍🍳 Start Cooking

For today's lesson, we'll be looking into how forge helps us build and test Smart Contracts

Let's create a folder named foundry-learn and move into that. Add a simple Counter contract using a forge command

forge init Counter

This will create a new Counter folder within your project folder. Once you move inside this folder you'll see a whole bunch of stuff, but let's just focus on 3 folder for now

• lib - Holds forge-std library, which helps us write Tests and Deploy scripts using pure Solidity

• src - Holds all your .sol Smart Contract files

• test - Holds all your .t.sol test files

We have our sample contract and test file in their respective folders. Let's look at how easy it's to test and build our contract

• Here's our Counter.sol code in src folder

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

// This is a simple counter contract that allows you to set a number,
// increment it, and decrement it, with a check to prevent negative values.
contract Counter {
    uint256 public number; // The current value of the counter

    // Sets the initial value of the counter
    function setNumber(uint256 newNumber) public {
        number = newNumber;
    }

    // Increments the counter by 1
    function increment() public {
        number++;
    }
}

The simple contract lets us write a number to a state variable and increment it by 1 by calling a public function

• And here's the Counter.t.sol test file in the test folder

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import {Test, console} from "forge-std/Test.sol";
import {Counter} from "../src/Counter.sol";

// This is a test contract for the Counter contract.
// It includes tests for incrementing, decrementing, and setting the counter value.
contract CounterTest is Test {
    Counter public counter; // Instance of the Counter contract

    // Sets up the test environment before each test
    function setUp() public {
        counter = new Counter();
        counter.setNumber(0);
    }

    // Tests if the counter increments correctly
    function test_Increment() public {
        counter.increment();
        assertEq(counter.number(), 1);
    }

    // Fuzz test for setting the counter value
    function testFuzz_SetNumber(uint256 x) public {
        counter.setNumber(x);
        assertEq(counter.number(), x);
    }
}

This tests if the state variable is being set properly and incrementing is working on function call

🏗️ Build

It's time to compile/build our Contract. To do that, let's run this command while in the Counter folder

forge build

Your Contract will now be compiled using the latest Solidity compiler

🧪 Test

To Test the Contract all you have to do is run this command while in the Counter folder

forge test

If everything is setup properly, you'll see that the tests passing successfully

And that's a Wrap! (For now 😬)

By now you should have

• Foundry and all it's tools installed in your system.

• Created Counter project using forge

• Understood important folder structure of generated project

• Built and Tested the simple Counter contract using forge

What's Next?

Part 2, we'll dig into

• Deploying your tested Contracts

• Interacting with deployed Contract using terminal commands

Don't miss it! I'll see you soon! 😎