Slides are here: https://drive.google.com/file/d/1IRLXuh6O8WWiTOXSyyWJ1sfCteri3V4K/view?usp=sharing

Christian Koopmann (https://www.linkedin.com/in/christian-koopmann-a97ab55b/) provided an introduction to the components of Foundy, with a focus on Forge.

My name is Peter Robinson and today I've got Christian on the line who's going to tell us all about Forge and related tools.

So Christian, why don't you introduce yourself before we start?

So can I just go ahead and share my slides?

I'm a long-time listener, first-time caller, so to speak, of the show.

And yeah, generally got into smart contract development during the COVID lockdown.

And yeah, I've been doing pretty much nothing else since then.

So I try to give back a little bit where I can.

And yeah, since, since pretty early in the in the founding project, I'm a big fan, I have a user, and even occasional contributor so I am super excited to be able to share a little bit about my enthusiasm and what I know about the project with you guys.

And yeah, if you have any questions, corrections, anything else, feel free to contact me on Telegram.

And if you want to see what I'm up to, you can also check out my GitHub account.

And so without further ado, I want to talk a little bit about Foundry.

Foundry is a smart contract development toolkit, so kind of similar to tools like Hardhead or Truffle, but It does a few things differently, which hopefully I'm gonna show today.

It is a, as far as I know, it's an extended port of a previous project called DappTools.

So if you've heard about that, you'll see that the interface and the philosophy behind it is very similar.

It is implemented in Rust, which makes it very, very fast.

And yeah, just As a side note, it's a great project also to get involved.

If you want to do some Rust open source work, they have an amazing community and really welcome new contributors.

And yeah, so it's also a great chance to learn some Rust.

And generally it consists of 4 components.

So a lot of the content out there about Foundry really focuses very heavily on Forge, which is kind of the main testing framework and compilation and scripting, But it's actually, it also has 3 other parts, which are very powerful tools in their own right.

And today I wanna give a bit of an overview of all of it and then dive a bit deeper into Forge.

So that's gonna be the structure of this talk.

We're gonna go through the 3 other tools, namely Cast, Anvil and Chisel, really quick and just kind of tease what they're about and what you can use them for.

And then the rest of the talk, we're gonna look into Forge, mostly into testing and then also a little bit into scripting.

And yeah, so the first tool that I want to talk about in the Foundry toolkit is Cast.

First, we're gonna obviously have to say a few sentences about how to get started.

So in order to use Foundry, because it's unlike hard hats, it's not a JavaScript framework.

And so you cannot install it with the npm or yarn what you might be used to.

Instead they have their own installer called foundry up and so the first command here basically downloads that installer and initializes it And then you will have in your terminal, you will have, or in your path, you will have this foundry-up command, and you can use that when installing Foundry for the first time, and also to manage versions, upgrade, downgrade, all that kind of stuff.

And yeah, once you have installed Foundry to Foundry app, you will have all the 4 tool kits that I said before.

So Forge, Cast, Anvil, and Chisel will be their own like kind of commands in a command line, which you will then use to basically leverage these tools.

Cast is a kind of tool that allows you to do all kinds of cool stuff when interacting with Ethereum or any other EVM compatible blockchain.

And so it's kind of for these ad hoc things, like you wanna get some data on a block, on a transaction, on an address, you want to make a call to a contract, execute a transaction, you can read specific storage values, you can do all kinds of encoding and decoding call data, and a lot more really.

So it's a great tool for debugging the state of any kind of chain or node, both like the actual chain, but also if you have a local test node and you wanna look at what happened there, it's really great tool.

And again, it has a huge amount of commands.

If you can use the help command to see all of them.

I'll just show 2 right now, which are really, for me have been great productivity enhancers and yeah, have really helped me a lot.

The 1 example of something cool you can do with Cast is called Cast Interface.

And so if you run the command cast interface and then the address of a contract, it kind of generates automatically a Solidity interface file for you.

So I don't know about you guys, but sometimes when I'm working on a smart contract and I'm integrating a third contract.

What I happen to do is look into their source code, copy paste the function, the function signatures that I'm using, and then deleting the function body and all that kind of manual quite tedious stuff to generate this type of interface.

And basically, Cast automates all of this for you.

And it makes sure that you actually have all of the functions of all the inherited contracts in your interface definition, which is great.

The way it does that, as far as I know, it uses like ether scan to get the contracts ABI and then generate this.

So this will most likely only work for contracts that are verified on Etherscan or are part of what you're developing locally.

But yeah, I think most cases that will be the case anyway.

And yeah, this also works with other chains.

Then you have to like give it a custom Etherscan URL.

But yeah, this is like really a neat little trick that saved me a lot of time already.

And then the second 1 is called Cast Run.

So Cast Run, and this is really, to be honest, even just for this 1 command, I think is worth installing Foundry for.

Anyone I've shown this has told me that this was a really game changer for them.

And what it allows you to do is basically kind of, it's really good for debugging transactions.

So what it will do is it will resimulate a given transaction on a local EVM.

So it will kind of fork the chain just prior to that transaction.

And then it will, in a local EVM, rerun the whole transaction and give you a whole trace of all the external calls that were called, errors, it gives you gas usage, it shows you when there were delegate calls, so you can easily understand when there might be a proxy involved.

So you rarely get the old, I don't know, reverted without reason or whatever that you might have, that has frustrated me a lot in the past.

If it runs out of gas, it tells you it ran out of gas and all these kinds of things.

So it's really, really good at finding quite often what went wrong or just generally understanding it.

And it even like all these tools, it can be run against a local node.

So the scenario where I find myself using this the most is actually when I have a project where I'm using hardhat and I have some kind of error in my tests and I'm not quite happy with the traces in hardhat.

I don't quite understand what went wrong.

I can run this command and get a whole more detailed view on the failed transaction, which is really, really great.

And yeah, if you want to go really, really deep, you add the dash dash debug flag, and then it will even open a kind of interactive debugger, EVM debugger.

So you can go through the transaction opcode by opcode and yeah, understand what went wrong.

And yeah, it's, I mean, this is a more advanced tool, but even without the debug flag, it helps me find the error in, I would say 4 out of 5 cases.

So that was Cast, or just a small subset of what Cast can do.

Anvil is really just kind of hard at node but faster.

So basically it runs a local, yeah, local nodes that you can run tests against.

You have kind of unlimited ETH in that local node.

It has all the features that you're used to.

So you can fork the main net at a specific block number and all that kind of stuff.

So in terms of NUMS functionality, it's really pretty much as far as I know, exactly the same, but it's just a lot faster.

So yeah, even just swapping your hardhead nodes with Anvil can really speed up your test execution or your CI.

And due to the kind of, because the RPC interface is the same, you can use these different, you can use it pretty much interchangeably with a hardhead node or with a truffle ganache or these tools, just faster.

And then the last 1 before we go to the testing is called Chisel.

This tool to be honest, I haven't really used in my day-to-day work yet.

I looked into this in preparation to this talk.

It's kind of, yeah, it's rarely even mentioned when people talk about Foundry as far as I know.

But it's quite neat in my experience in preparation.

And what it is, is basically a REPL, so a read, evaluate, print loop for Solidity.

And REPL is pretty much the same that happens when you just type Python or Node in your terminal.

So you can do a kind of interactive programming where you type in each command and you can immediately see each variable's value and do all kinds of tests.

And here you can do all of that in Solidity.

So you have access to pretty much the whole Solidity syntax.

As you can see up there, you can specify a specific block number and then the code will be executed as if it is a transaction at the beginning of that block.

And so, yeah, I could see this also being very useful for some iterative development or some debugging.

So before we go on to the main part, which is about the testing, does anyone have A question about these tools or about Foundry in general?

I think there are a few questions in the chat.

So Cast Run basically just reruns an existing transaction.

So it reruns a transaction that has been submitted and included in the blockchain already.

For integration tests, we'll look later at Forge, which is the testing tool for both unit and integration tests.

So yeah, this is mostly for rerunning transaction, but if you have an integration test on your local node running and it fails, then you can use cast run to debug that integration test and maybe find out where it went wrong.

So that value there, that 0xacff is the, what, the transaction hash, I guess.

So Dev asked, and I think they may have misunderstood, you had mentioned that it decoded the function details, even software source code is not verified.

And I think it, you were saying you thought it had to be verified for it to work.

No, actually, I forgot to mention this because it's really cool.

Of course, as a first, I mean, I didn't fully look into the implementation.

It might have changed, but my understanding is such that it first checks if the contract is verified on Etherscan or any other explorer, and then it will use that.

But it has a fallback, and it used something called the full byte registry.

This is like an online repository of function selectors.

And it will, if the function selector is in this 4 byte registry, it can decode a function, even if the contract is not verified on Eclascan.

So obviously it cannot, like it won't work for any, for all of them, but In many cases, yes, it can even decode unverified contracts.

Yeah, so then the next topic in the main tool in the in the funding toolkit that we're going to talk to kind of talk about is Forge.

And Forge is, yeah, what sometimes people even use Forge and Foundry like interchangeably when they're really just talking about Forge.

And it's the kind of, it's the tool that contains the testing, the deployment, the contract compilation, managing your solidity project.

So it's really like the core tool that you're using when you're when you're developing a smart contract.

And so in that sense, it's kind of similar to functionality of things like hard hat, but it has a bunch of differences.

And the main difference is that everything, or pretty much everything you will be writing is in Solidity.

So the tests are in Solidity, the scripts in Solidity.

Of course, the contracts that you're working on are usually, I mean, can be in Vypr, but usually also in Solidity.

So in most cases, you will have no context switching because you're doing everything in Solidity.

And then it's also, as before, it's very, very fast.

And because you're doing everything in Solidity and in a smart contact, there's a lot less boilerplate code when interacting with the chain.

And yeah, also it has these improved error traces, what we showed, what we looked at earlier with the cast run, these kind of detailed traces you have in a lot of places in Forge, in your tests and everything.

And then it also has some really cool advanced testing features that go beyond what you would normally do in the existing toolkits.

And those are fuzzing and invariant tests.

And we're gonna talk about those later as well.

And so Basically you can do everything and more that you could do with existing toolkit and you're gonna be a lot faster.

And again, when you have installed Foundry, you will have the forge command in your path.

And so usually start by setting up a project using the forge init command.

And what that will do is it will create a kind of a template project.

It's the standards like counter example where you can increment a number.

And then it also contains some example tests and an example script.

You can see that all of these end in SOL because as I said before, everything is written in Solidity.

I'm not gonna go in too much into the configuration file, but it's kind of, it's got pretty sane defaults, but you can pretty much change anything in there if you want to.

So you can change the RPC URL, the block number, you can change the compiler version, all that kind of stuff.

And then it also has this lib folder where you find the dependencies.

And because Forge is, again, it's not a JavaScript project, so it cannot use like your standard JavaScript package managers to manage dependencies and libraries.

And so it has kind of its own system, which is based on a Git sub-module, which is kind of a bit of an advanced Git feature, but basically allows you to quickly install any dependency that is on Git.

So it doesn't have to be on any like NPM or anywhere.

You just say forge install and then kind of the GitHub repo name and owner.

And then it will basically just download that repository and kind of link the files such that you can then import it, import the contracts elsewhere.

And yeah, so everything is in Solidity, including the tests.

So this is the very, very simple test, slightly adjusted from the template example.

And to create a test, all you need to do is first you need to create a contract.

As usual, everything in Solidity, and so everything also in these tests and scripts, needs to be wrapped in a contract definition.

You inherit from this test contract, which is provided by Forge and which gives you access to all kinds of assertion functions and all kinds of tools that you need for your tests.

And then, yeah, you have a setup function that is run before every single test.

So it's equivalent to before each in the JavaScript setup.

So yeah, this function is run again before each test.

So you can have a clean setup for every test.

And then Forge will recognize as a test any public function on this contract that starts with the word test.

So yeah, that's how you kind of tell Forge or run this as a test.

And then you have a variety of different functions from the inherited test contract, such as assertions like we do here.

So this is a very simple test where we just increment the counter and then we check that it's the numbers 1 afterwards.

And yeah, so this is basically the most basic test setup you can have really in Forge.

And once you have defined your test, you can run it with Forge test.

As usual, there are a whole bunch of different arguments or like parameters that you can pass to specify how these tests are run.

So you can use regex expressions to only run specific tests.

You can run them against specific block numbers, all kinds of stuff.

You can make it such that on a failure, you, you enter the debugger that I showed earlier.

But, normally most of the loss you don't need, what's really good to set is the verbosity.

So, here in this case, dash VVV means we have a positive level 3, which means that we get the traces on every failed test.

And so here I kind of adjusted the test a little bit to have a failing test, just to show what it looks like.

And yeah, again, you get the same kind of really detailed traces that you also got in the cast run argument that can really help you debug what went wrong in your test.

And also here in this screenshot, you will see how fast it is.

So less than 1 millisecond that it took for this test to run.

And yeah, now any questions regarding how to set Forge up, how to initialize your project, how to run a basic test?

So this is obviously, this was a very, very basic example.

And in many cases in your tests, You actually want to do a little bit more.

You don't just want to have these basic assertions, but quite often you need to do things like, oh, I want to check that maybe only the owner can call a specific function or something else.

So in many cases, you want to check that certain things don't work under certain conditions.

So you want to basically check for reversions.

And this is something where maybe you think, oh, I only have the normal solidity syntax at my fingertips.

But Foundry has got you covered with that.

So there are 2 ways of having a test that kind of checks for a reversion or a failure.

The first little bit more crude example is to just call, add the word fail to your test name.

So if it's test fail, then Forge will run this test and it will expect there to be a reversion anywhere in that test.

And so if there is a reverse in that test, it will be green.

And if this function runs without any reversion, then Forge will complain.

But yeah, I would say the somewhat better way to do it is to use the expect revert function that also comes with this test contract.

And that allows you to check for a specific, for a specific reversions or specific reason error in the very next call.

So here in this case, we are checking for an arithmetic underflow error in the decrement function.

So in this last test, and normally in this expect revert function, you would just type in as a string the reason that you expect.

In this case, this underflow error is a solidity compiler level error.

So it's not an error reason that we define ourselves.

And so for this case, there is this standard error library that Forge also provides that contains the error data for all these kind of compiler level errors that is quite handy if you want to check for these kinds of errors.

But yeah, normally if you have an error you defined yourself, you would just type in your error message there.

And this is actually the first example of what is called cheat codes in Foundry.

So this vm.expectrevert is a quote unquote cheat code.

And cheat codes are these kind of functions that are added by Foundry that extend the normal solidity syntax to allow you to do all kinds of quote unquote fancy stuff that you might want to do in your tests, but you normally cannot do on Ethereum.

So using these cheat codes, you can control the message sender.

So you can check, for example, your access control.

You can control the block number, the block time, really anything about the state of the blockchain at the point of the test.

You can check for reversions, what we just looked at.

You can check for event emissions, which we're gonna look at next.

You can interact with things outside of the EVM, such as your file system, your environment variables, your CLI commands, and a lot more.

So quite often when you come to a point where you think, ah, probably cannot do this with Foundry, they'll more likely than not, there'll be a cheat code or a combination of these cheat codes that let you do what you want to do in your test.

And yeah, Another cheat code that is quite useful during tests is this expect emit cheat code.

And so what this allows you is to test that a certain event has been emitted.

So up here we see in the top we see a snippet of the implementation of the contract that we're testing.

And it's still the standard counter contract, but here we added like just a little, like just emitting an event when we increment the number.

And now below is the test that checks that the correct event was emitted.

And this, to be honest, is a little bit more complex maybe in the Foundry case.

You have to kind of copy paste the event definition into your test.

Then you have to call the expect the mid cheat code and you have to tell it which parameters of the events you want to check for in your test.

So in this case, our event has just 1 index parameter.

So we set the first flag to true and all the other ones to false.

But normally, yeah, the first 3 flags refer to the maximum 3 indexed parameters of an event and the last 1 to the rest of the data.

See all Ethereum Engineering Group transcripts on Youtube

Solidity Development with Foundry: Cast, Anvil, Chisel, and Forge