19. Cyfrin Updraft: Foundry Simple Storage

Overview

This external Cyfrin Updraft chapter introduces Foundry, the second major smart-contract toolchain alongside Hardhat. Where Hardhat tests in JavaScript, Foundry lets you write tests in Solidity and is prized for speed. The teaching is on Updraft; these notes frame why it’s here and what to take away.

Why Foundry matters

• Solidity-native testing — you write tests in the same language as your contracts, so there’s no context-switch to JavaScript. Many professional teams standardize on it.
• Fast feedback — Foundry’s test runner is very fast, which keeps the edit→test loop tight (the same loop discipline from Module 2).
• A second toolchain in your vocabulary — seeing the same “simple storage” contract built and tested in Foundry, after doing it in Hardhat, shows you what’s essential (the contract, the tests, the deploy) versus what’s just tool-specific.

Concepts to lock in

• forge — Foundry’s build-and-test command; you compile and run tests with it.
• Tests as Solidity contracts — a test is a contract with functions that call your contract and assert results.
• Toward deploy scripts — this chapter sets up the scripting you’ll use to deploy programmatically, which the Module 5 Foundry deployment lesson builds on.

What to bring back

You should be able to build and test a simple contract with Foundry and articulate the trade-off between Foundry (Solidity tests, speed) and Hardhat (JS ecosystem). You don’t have to pick a favorite — knowing both is the point.

Check yourself

• What language do you write Foundry tests in, and why is that convenient?
• Which command builds and runs tests in Foundry?
• Name one reason a team might choose Foundry over Hardhat, and one reason for the reverse.

Open Course Segment

Cyfrin Updraft: Foundry

Assignment: complete the Foundry Simple Storage chapter.

Open Foundry course on Updraft

Course Position

Module 3: Full-Stack dApp Basics.