Foundry: A Comprehensive Smart Contract Development Framework

Foundry revolutionizes smart contract development with its fast, built-in fuzzing and Bash scripting, making testing and deployment effortless.

### Getting Started with Foundry: Smart Contract Development Framework
* 🚀 Foundry is a new smart contract development framework that enhances the **speed and ease** of building, testing, and deploying contracts.
* 💻 To initiate a Foundry project, download Foundry or Forge from the GitHub repository by running a simple **curl command**, which will set up the **necessary tools in your terminal**.
* 📁 The essential code for the project can be found in the GitHub repo named **Foundry Play**, and for advanced users, the Foundry starter kit offers a **comprehensive template with Chainlink smart contracts**.
* 📚 One of Foundry's standout features is its educational book, which provides **detailed guidance on using the framework**, making it an **excellent resource for developers**.
* ⚡ Foundry boasts advantages such as **speed**, built-in fuzzing for testing, Solidity-based testing, and the use of **Bash or shell scripts**, making it **user-friendly for developers** familiar with these languages.
* 🛠 To create a new project, the command `Forge init` is used, which sets up a **library, source folder, and test files**, allowing for **easy management of dependencies and tests**.
* ✅ Built-in fuzzing allows for chaos testing by **automatically generating random test cases** to identify potential failures, ensuring **robust smart contract functionality**.
* 🔧 Finally, deploying contracts locally can be achieved by integrating Hardhat, which facilitates **running a local blockchain for testing and deployment**, enhancing the overall development experience with Foundry.

When you're building your smart contracts, you care about how quickly you can do it, how well you can test them, and how you can deploy and interact with them. Foundry is a new smart contract development framework based off of dapp tools. It's what we're going to be going

over today. Let's learn Foundry. All right, so to start a new Foundry project, you first need to download Foundry and or Forge from the GitHub repo. So we can look up Foundry ETH and we can come to this repo here. And then this is all you

need to do to run it. Run this curl and you'll get Foundry up. And then you can go ahead and just run Foundry up in your terminal, and you should have Forge and cast, and then you should be good to go. And a quick note, per usual, all the code

that we're going to be working with is on my GitHub repo. Link is going to be in the description. It's called Foundry Play. And if you want to see a more advanced repo in this smart contract kit, we have a Foundry starter kit public template

which goes way more in depth. It has a lot more advanced testing, some advanced scripts and everything, and it works with the Chainlink smart contracts out of the box, so that you can just use this template, get going with it right away. So absolutely be 100% sure to check out The

Foundry starter kit after this video. And additionally, one of the coolest things about Foundry is that it actually has a book where you can kind of learn, similar to the Rust book, right? You can go right through it and learn everything you need to know about working with Foundry, so

like I was saying some of the main advantages of Foundry is that it's fast, it's got built-in fuzzing which you'll see in a bit, it's got Solidity-based testing and it has a bunch of EVM test codes, and the scripts are based in Bash

and or shell, it's really similar to DAP tools which we've demoed before. This one's even faster than DAP tools which is really fantastic. Some of the built-in fuzzing and Bash and shell scripts make development, testing and deploying really easy and fun. So if you don't want to

have to learn JavaScript, if you don't want to have to learn Python, you pretty much are always going to have to know Bash, so this might be the framework for you. So let's go ahead and work through it. So to get a new project started, we do

Forge init. I'm going to do d-force because I created a README file in here, and it's going to create a new project. And let me just walk you through what files it just downloaded for us. We see on the left here, it downloaded some

files. So first we have a lib, this is our library. You can kind of think of these as the dependencies for our package here, right? The main contract in here is this Test.sol, which has a bunch of really nice stuff for testing which we go over

in a little bit. So the first dependency we downloaded is this DS Test. Then we have our SRC, which is the equivalence of a contracts folder. So in DAP tools, it just does SRC, you know, when Hardhat and Brownie uses contracts, but that's it. And then

Obviously we have our contracts in here and then we also have our tests in SRC, which is the main differentiator, right? So we have these tests. The syntax is contract name . t . o, and when we run our testing, we can run Forge test and it'll just run

through these like that, right? So you see compiling three files, compiler run successful, and it'll even give you this little gas outdate, which is really nice. So that's how we run tests there. Git ignore is ignoring files for Git. Git modules is where we actually define

what GitHub repos we want to pull in into our lib folder, and then we have our founder. This is kind of like your hardhat config. It's got a whole bunch of nice parameters in here and it's even got a little link to more about the

config file, and then obviously I just added a README in here. So that's the basis of how this actually works. Now let's actually look at this testing thing. What is this built-in fuzzing? What do these solidity tests look like, right? Let's go ahead and build one of those. So

let's create a contract here, right? Let's delete all this. We'll create a new contract, we'll call it StakeContract.sol. So we're going to look at a really, really, really tiny stake in contract, right? So let's create it from scratch.

pragma solidity ^0.8.10; SPDX-License-Identifier: MIT; import '@openzeppelin/contracts/token/ERC20/ERC20.sol'; contract

stake contract now the first thing that you want to try right now is probably compile this right so we can do Forge build to try to compile and we're going to run into an issue right away it's going to say hey what is this what are

you talking about here and this is the first thing that we're running into so a we don't have this installed here and for Foundry Foundry doesn't know that this is actually going to be pointing to our lib folder so the first thing that

we're going to do is we're going to need to install this and Forge actually just looks directly at GitHub and installs from there so we'd want to go to the OpenZeppelin contracts page and this is what we're going to tell it to install

OpenZeppelin OpenZeppelin contracts because it installs right from GitHub so we do Forge install OpenZeppelin OpenZeppelin contracts and now it's going to go ahead and install that installed opens up in contracts if we look in lib we actually

see that in here now and if we look at git modules we see that OpenZeppelin contracts has indeed been added which is perfect which is exactly what we want so now we have these two git sub modules in here now if I do Forge build we still

have an issue because it's saying hey I can't find that right so we need to do what's called a remapping and this is where our Foundry.toml is actually going to come into play here so right now we're remapping DS test which is good

we're going to do a little comma here and then we're going to say at openzeppelin SL equals lib slopen Zeppelin Pyon contracts slash so it's saying hey anytime you see openzeppelin you're going to point to lib openzeppelin

contracts right and that's what we want so point to openzeppelin contracts let's see if it does this boom and now it's finally successful because we've imported the openzeppelin contracts and we've mapped it correctly awesome and then actually this should be IERC20

because we're just going to do the interface of the token So Okay cool so we have this contract let's go ahead and make it just so that it can deposit right just so it can deposit so we'll do a mapping of addresses to uint256 make it

public so our balances and this will represent how much money each address has and then we'll just do function stake and it'll take a uint256 amount it'll take an address of the token it'll be external external and it'll return a Boolean why not so how do we actually

stake here so we'll say s balances of message. sender plus equals amount so we're going to keep track of the balances of this person actually should do balances token this should be a mapping to a mapping so the balance of that user of the token plus equals

amount then we're going to transfer the IERC20 token transfer from message. sender to address this for the amount and then we're going to do if not success revert we're going to do a custom error code in here we'll do error transfer failed some nice version eight

of solidity stuff here and then we're just going to return success so great so what does this do all it does is it sends this token to our contract here that's all it does and that's where we're going to stop we're just

implementing in the stake function but you'll see this is a sufficiently complex function for you know the test that we want to write cool and let's just make sure it actually works with Forge build looks like we ran into an issue here should be returns bool

bool success equals there we go okay now we're building correctly awesome so that's how you actually build a contract cool now we have a contract built let's go ahead and test it we're going to change this we're going to call this stake contract.t.sol and this is

where we're actually going to test our staking function our staking contract here so we'll leave this up here for now this test.sol is what we're importing and inheriting from our DS test and actually I'm going to change this to stake contract test is DS test this

means we inherit all that stuff from DS test and if we look in DS test it's got a whole bunch of stuff right it's got all these events that we can emit out it's kind of like a console.log like if we wanted to see you know a certain

address we could emit it as an event we have this vm address which are cheat codes which I'll talk about in a minute we just have a whole bunch of functions that we can use for a test one of them is a search room right because we're

testing in Solidity so we need all this stuff to actually test in Solidity so this is kind of one of the defaults that we're going to import in obviously we're going to import in our state contract. Soul right because that's the one that we're testing and then since

we're working with ERC20s we're probably going to want to have a test ERC20 right so that's where I'm going to create a new folder in here call MOX new file mock erc20 dot sol and I'm just going to copy paste this in here it's a

really really small ERC20 feel free to check the GitHub repo to see this uh this actual code so you can use it but this is what it's going to look like here okay so once we have our mock we're going to import that as well do import

slmm erc20 dot sol and now we can actually start with our test right so right now if I run forage test it's just going to automatically pass because that's all we're doing here right we're running Test example assert true so our setup

function is what it's going to call before your tests so this is what you want to do to like create all your variables and anything and since we're going to be testing our state contract we'll create a global called or a storage variable called State contract

State contract and then in here we'll do state contract equals new state contract and then we'll also do a mock ERC20 we'll say mock ERC20 public Mo erc2 Mach ERC 20 equals new Mach ERC 20 so

now we have a state contract we have a mock ERC20 let's go ahead and write some tests let's just write one test let's just test to make sure that we can actually stake something so first we're going to do mock token.approve right

because in order to actually call transfer from you need to approve address of state contract amount we'll say uint256 amount equals know 10 E18 which this is 10 * 10 raised to the 18th because again solidity doesn't really work

with decimals so well mock token.approve and then we'll do BU stake passed equals stake contract.stake amount address mock token and then we'll do assert true stake passed right so what is our test doing all our test is doing is saying hey is this stake thing

returning true right we probably would want to to see that the token was actually transferred the balance was actually updated but for us we're just going to do like this now we'll do Forge test and we'll see we ran into an issue because I said Mew instead of new called

that mock your C20 I'm actually going to change the name to mock token because caps are better and boom awesome so that's how you write a really really basic test in Foundry in solidity okay now one of the things that's fantastic about Foundry is it has this thing

called built in fuzzers if I pass a parameter to my test here it's going to loop through a whole bunch of randomness of that value and and try to use that to like break your smart contract which is awesome so for example if I pass uint256

amount and I delete this line here and we rerun it let's see what happens oh we got some failed here right what's going on transfer amount exceeds balance so it's saying hey there's too much token in here right like we have our mock only

this high right but if we pass some random U 256 that's too big this this function will fail right so this is a way to almost like chaos test like for random variables random attributes in your application now if we tweak this a little bit and we do U 8 it'll

definitely work right because U 8 is going to be much smaller than a u 256 right A U 256 it might test with you know like that number versus the un8 is going to be like 255 right or or whatever it is but now when we run Forge

test here we see we get this runs bit down here we see Test example runs it did 200 56 runs so it tried 256 different numbers for this amount here and it kept trying until it found something that would make it fail and it didn't find any that make it failed so

it passed it but if we were 256 it's obviously a lot easier for it to find a failure right because it's just going to pass a massive number that's way too big right so that's kind of the difference that's what this chaos testing does and

it allows for us to check for stuff that you wouldn't even think to check for which is incredibly powerful especially especially in solidity now one of the other wild things that Foundry comes built in with is this thing called cheat codes so I'm going to create an abstract

contract in a new folder called utils. I'm going to call it cheats.sol and I copy-pasted some code. Don't worry too much about it, but basically it's an interface or an abstract contract of different functions that we can call on our Foundry environment to

move block time, to change a whole bunch of different things and just really mess with anything we want in our blockchain. Right? If we want to set the block timestamp to a certain thing, we have a function that can do that. If we want to set the block number, if we want to store

a variable at a certain spot in memory, if we want to expect to emit something or expect something to revert, we can do all these things to a blockchain ourselves, which is incredibly powerful. So, back in our state contract.sol, we do import utils/cheats.sol. We'll make a

new cheats. We'll do cheats internal constant cheats equals Cheats.address. So, there's a special address on our Foundry blockchain when we run these tests that is this cheats address that we can call these different cheat functions on, and that's what we do. We

say, okay, great, we're going to be working with this cheats address here. And then what you can do, for example, like maybe you wanted to see if your test still works on different block timestamps or different numbers, you do cheat.roll(55) or something like that, right? And maybe

we'll do, we'll do this after we do cheat.roll. So now we're testing to see, hey, does this work on block number 55? We can run Forge tests, and we do indeed see that it passes. Right? So we can do all these, all these different things to

manipulate our blockchain so that we can test literally any situation, which is incredibly powerful. All right, cool, so we can test our contracts and build our contracts. What else can we do? Well, we probably want to make some scripts to actually work with our contracts and

deploy our contracts. Now, most of what you'll see in Foundry and dapp tools, you'll see most scripts in Bash or some type of shell scripting language. And then additionally with that, you'll see, see kind of the main file be this thing called a make file. Make files are ways

to actually just kind of collect your scripts and collect what you want people to do with your application. So I'm going to copy paste our make file in here because it's highly likely you're not going to be actually building your make files yourselves; you're probably going

to be copy pasting them yourselves. So I'm just going to walk you through basically what's going on in this make file. So first thing is this include.env. If you have any environment variables, you can put them in a .env file and you do like

private key equals, you know, 777. You do like RPC URL equals Alchemy.do.io blah blah blah, like that type of thing. We have this all, so whenever we run make, we're going to run all these things here. And I'll explain what that is in a

second. We have this solc command. And in make files, when you see this like colon semicolon, it means this is a command. The solc thing installs the latest version of Solidity, which is great. Clean, which is going to kind of remove and reset the repo. Remove modules, which is going to

remove the modules obviously install it's going to run these two install commands the same one that we just ran update is going to update any dependencies build is going to actually build our contracts and then we have some yarn stuff which I'll talk about in a second but for example we can run

Forge build it's going to be the same as if I ran make build well not quite the same because this has some optimizations in it but this make file is typically how you'll see dependencies and everything set up so if I run make it'll kind of read do everything it'll

reinstall everything and this is typically the first step that you'll take on one of these repositories is you'll run make and you'll be good to go which is really exciting now if you want to deploy to a local network we're going to have to spin up a local network

ourselves if we want to deploy to a test network or a real network let's show you how to do that so first let's show you how to deploy to a local network so the first thing we're going to do is we're going to actually add hardhat into here

and hardhat's going to be what we're going to use to run our local networks so we're going to do yarn add hardhat and if you don't have yarn you can also do npm uh install hardhat there should be some links in the description to

actually get hardhat if you need this and then what you can do is yarn hardhat and we're just going to say create an empty hardhat config then we can do yarn hardhat node now we have a fake blockchain running on our local

Host, which is really exciting. Let's grab this private key and we'll add it right here, so we'll say private key equals this guy right here. Now, in a new terminal, what we're going to do is we're actually going to deploy our stake contract. We're going to do Forge create

State contract, D- private key, and we're actually just going to paste that private key. Um, in our scripts later on, we'll, we can use the private key, and then you do D- RPC URL, right? And this is where you put your Alchemy URL for

mainnet, for Polygon, for Avalanche, whatever. For us, since we're deploying to local, we can actually copy and paste this like so. But also, if you don't give it one, it'll just automatically deploy to local. So, we're just going to leave it blank for now and going to hit enter, and

it's actually going to go ahead and start deploying it for us. If we look at our node that's running, we're deploying a contract right here. We go back here, it says hey, it's been deployed, you're good to go. And now we have that contract

deployed on our local node. So, that's kind of all the basics of Foundry. Like I said, if you go back to this book, it is absolutely phenomenal. It gives you even more skills and even more really cool, interesting things that you can do with

this. It's an incredibly active repository, right? If you look at it, 12 hours ago, yesterday, couple days ago. So, they're building this to be an insane tool. So, definitely be sure to check out the GitHub repo as well. Feel free to contribute, and then absolutely be sure

to check out The Foundry starter kit for more advanced uses of The Foundry repo, definitely go check that out. Have fun, talk to you next time. [Music]

Intro to Foundry | The FASTEST Smart Contract Framework

Patrick Collins

Introduction to Foundry and its advantages

Foundry is a smart contract development framework based on dapp tools, focusing on speed, testing, deployment, and interaction.

Installation via GitHub repo using a curl command.

Code examples available on GitHub ('Foundry Play' repo).

A more advanced 'Foundry starter kit' template is available.

Foundry offers a comprehensive learning book.

Key advantages: speed, built-in fuzzing, Solidity-based testing, EVM test codes, and Bash/shell scripts.

Creating a new project using 'Forge init'.

Project structure includes 'lib' (dependencies), 'src' (contracts and tests).

Test files follow the naming convention 'contractName.t.sol'.

Includes '.gitignore', '.gitmodules', and 'foundry.toml' files.

Installing OpenZeppelin contracts using 'Forge install'.

Using 'foundry.toml' for remapping dependencies.

Creating a test file 'stakeContract.t.sol' using DS Test.

Utilizing built-in fuzzing for testing with random inputs.

Creating an abstract contract 'cheats.sol' for cheat code functions.

Importing and using the 'cheats' contract for manipulating blockchain state.

Example: Using 'cheat.roll' to test with different block numbers.

Using Bash/shell scripting and makefiles for managing scripts.

Makefiles structure and functionality, including environment variables.

Deploying to a local network using Hardhat.

Deploying the contract using 'Forge create' with private key and RPC URL.