> For the complete documentation index, see [llms.txt](https://blockchain-journal-hope-mabuza.gitbook.io/blockchain-journal-hope-mabuza-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://blockchain-journal-hope-mabuza.gitbook.io/blockchain-journal-hope-mabuza-docs/smart-contracts/week-4-professional-engineering-hardhat-foundry-and-unit-testing-..md).

# Week 4 : Professional Engineering (Hardhat/Foundry & Unit Testing).

#### Day 22 <a href="#day-22" id="day-22"></a>

**Moving to a Professional Setup and Why Testing Matters**

* This week we moved from Remix to professional local environments. Remix was fine for getting started but this feels like a proper step up. The phrase that stuck with me today was "Code is Law". It means that once a smart contract is deployed, it cannot be changed. There is no hotfix, no patch, no way to go back and fix a mistake. Whatever is in that contract is what users interact with, forever. Coming from web development where you can push an update anytime, that was a bit of a shock to me. It makes testing feel less like an extra step and more like the most important thing you can do.
* I also learned about two main tools for local development. Hardhat uses JavaScript for testing and is more beginner friendly, while Foundry uses Solidity for testing and is faster. Since I already know JavaScript, Hardhat feels like the natural starting point for me. I can see myself exploring Foundry later but for now Hardhat makes sense.

***

#### Day 23 <a href="#day-23" id="day-23"></a>

**Setting Up Hardhat Locally for the First Time**

* Today I initialized a local Hardhat project using `npx hardhat init`. I ran the sample tests and saw green passing ticks in the terminal, which honestly felt exciting for something so simple. It just confirmed that my setup was working and I was ready to actually build something.
* Moving away from Remix felt like a big deal to me. In Remix everything just works in the browser without any setup. Going local means dealing with terminals, file structures, and package installs, which was a bit intimidating at first. But once it was running it felt much more like real development. I'm starting to understand why professionals don't use Remix for actual projects.

See screenshot below:

<figure><img src="/files/eP6pJzD5FfEda5znrzMh" alt=""><figcaption></figcaption></figure>

***

#### Day 24 <a href="#day-24" id="day-24"></a>

**Happy Path vs Revert Path Testing**

* Today I learned about the difference between the happy path and the revert path in testing. The happy path is testing whether the contract works correctly when everything goes as expected. The revert path is testing whether the contract correctly rejects things that should not be allowed, like invalid inputs or unauthorized actions.
* Before today I only really thought about testing whether things work. It hadn't clicked for me that testing whether things correctly fail is just as important, especially in smart contracts where real money is involved and there is no way to patch things after deployment. A contract that works correctly but doesn't block misuse is still a vulnerable contract.

***

#### Day 25 <a href="#day-25" id="day-25"></a>

**Test Driven Development and Writing My First Unit Tests**

* Today I practiced Test Driven Development by writing unit tests for my custom ERC20 token. I wrote tests to verify:
  * Tokens can be transferred successfully.
  * A transfer fails if the sender has insufficient balance.
  * The total supply is minted to the deployer.
* The revert test was the most eye opening one for me. Seeing the contract correctly reject an invalid transaction and having a test confirm that made the whole concept of defensive programming start to make sense in a blockchain context.
* Debugging also taught me a few things I wasn't expecting. Variable scoping tripped me up, where a variable I declared in one place wasn't accessible where I needed it. Function names had to match exactly or the test would fail silently, which was frustrating to figure out. And when using fixtures in Hardhat, I had to destructure the returned objects properly or I'd end up with undefined values and no clear error message. Small things but they cost a lot of time when you don't know what to look for yet.

***

#### Day 26 <a href="#day-26" id="day-26"></a>

**Submitting Milestone 2 and Reflecting on Access Control**

* Today I finished and submitted my Custom ERC20 token for Milestone 2. I added an owner-only mint function so only the deployer can create new tokens. I also wrote tests to check that the total supply goes to the deployer, transfers work correctly, transfers fail when someone tries to send more than they have, and that only the owner can mint.
* Completing this felt good. A few weeks ago I was copying contract code and hoping it worked. Now I'm writing tests that actually prove it works, and I'm starting to understand why access control matters. If anyone could call the mint function, the entire token supply could be inflated and made worthless. That's not a hypothetical, that's the kind of thing that has happened to real projects. Understanding it at this level makes it feel real rather than just theory.

***

#### Day 27 (ABC) <a href="#day-27-abc" id="day-27-abc"></a>

**Connecting Smart Contracts to a Server with ABIs**

* Today at ABC we focused on the lottery system and learned how to use the ABI of a smart contract with a server running Node.js and Express. This lets you automate things like starting and ending lottery rounds and distributing rewards to winners, without anyone having to manually trigger the contract each time.
* Before today I thought of smart contracts as standalone things that just sit on the blockchain. This showed me that you can connect them to a regular backend server, and the ABI is what makes that communication possible. It tells the server what functions exist on the contract and how to call them. Seeing the contract and the server work together made everything feel much more connected than I expected, and it opened my eyes to how real applications are actually built on top of blockchain.

***