Run the command:

npx hardhat test .\test\Erc20\TestToken.js

You should see the output as shown here

The command npx hardhat test runs all the test files in the /test folder, to run a specific test file, you can use the command npx hardhat test fileName.js.
You can also run multiple tests by concatenating the file names.

Since these are JavaScript files, the initial lines are dedicated to importing necessary modules. Chai is used for expect statements.

const { ethers } = require("hardhat");

Hardhat tests are divided into sections and in our setup, we're not utilizing fixtures. Instead, each test uses the same state as we want to keep things simple and avoid unnecessary complexity.

By default, when you run any script or test in Hardhat it uses the "hardhat" network. If you look carefully our current setup is forking Ethereum network on startup in the hardhat netwok

npx hardhat run .\scripts\Erc20\DeployToken.js

You will get EXACTLY this.

script running on network ID:  31337n
owner address:  0x696b217e6f4609316037bfbA77b3B65Bd0369Ac5

--🟡Executing script 0🟡--

⚪Deploying token...
✅token online on: 0x9DEC830dD1f5Cf005005Ac6261D651fd85701B10

--🟢Script 0 Done🟢--

All done.

By default when you run an hardhat script, one main function is executed. In my workspace instead, we choose what should be done.

Starting from the top, import the necessary modules and define the global variables that will be used throughout the script.

let chainId
let token
let tokenDecimals
let router
let owner
let routerAddress = "0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D"

The router address is for the Uniswap v2 router at https://etherscan.io/address/0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D. Since we are forking the Ethereum mainnet, we'll be adding liquidity there.
The following represents the core logic of the script: What the function does:

• Initializing the script
• Defining the tasks to be executed using "stepsToExecute" array
• Running through the tasks until completion

The function that determines which task to execute is defined here: By default, the script runs case 0. In our case, this corresponds to deploying the token contract and printing it's address once deployment is confirmed.

Each function in this script represents a task, following this structure:

async function deploy_token_contract() {
    const tokenName = "token Name";
    const tokenSymbol = "token Symbol";
    const totalSupply = 1000000; // 1M

    console.log("⚪Deploying token...")
    token = await (await ethers.getContractFactory("Token", owner)).deploy(
        tokenName,
        tokenSymbol,
        totalSupply
    )
    await token.waitForDeployment()
    console.log("✅token online on: %s", token.target);
}

Within that function, we:

• Define local variables with token name, symbol and total tokens to mint
• Add console logs before and after the contract call
• do the deployment tx & wait for it's confirmation
• Print the deployed address

Now, you have two options:

1. Run cases 0 and 1 together, but comment out "await attachContracts()"
2. Apply the deployed code within the script

In most scenarios, it's safer to proceed step by step. Run case 0 to obtain the deployment address. In our case, it's 0x9DEC830dD1f5Cf005005Ac6261D651fd85701B10

The "attachContracts" function is used to associate all the necessary contracts for executing one or more tasks. Add the contract address we got from deployment script output to the global variables at the top of the file:

let chainId
let token
let tokenDecimals
let router
let owner
let routerAddress = "0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D"
let tokenContractAddress = "0x9DEC830dD1f5Cf005005Ac6261D651fd85701B10" <--

Then, modify the "token" line, passing the address as a parameter: Now, whenever you need to run a task that involves interaction with our token and/or the router, you can directly call the "token" or "router" object within your functions.

Edit the "stepsToExecute" list and add case 1, like this:

const stepsToExecute = [0,1]

Now, run the script again.

script running on network ID:  31337n
owner address:  0x696b217e6f4609316037bfbA77b3B65Bd0369Ac5

--🟡Executing script 0🟡--

⚪Deploying token...
✅token online on: 0x9DEC830dD1f5Cf005005Ac6261D651fd85701B10

--🟢Script 0 Done🟢--


--🟡Executing script 1🟡--

✅Contracts attached.
⚪approving router...
Router approved.
Ratio: 100000 Token:10 ETH
⚪Adding liquidity...
✅Liquidity added.

--🟢Script 1 Done🟢--

All done.

The script performed two tasks even though you executed only one command!

This mechanism provides significant speed leverage.
How?
It allows me to deliver contracts in a short period of time with low effort, without compromising security.
(Spoiler: Foundry also do this.)

But what happened here? simple, we called addLiquidity() in the case 1 Let's take a look

async function addLiquidity() {
    const amount = ethers.parseUnits("100000", tokenDecimals)
    const amountETH = ethers.parseEther("10")
    
    console.log("⚪approving router...")
    let tx = await token.approve(routerAddress, ethers.MaxUint256)
    await tx.wait()
    console.log("Router approved.")

    console.log(`Ratio: ${amount/10n**tokenDecimals} Token:${amountETH/10n**18n} ETH`)
    console.log("⚪Adding liquidity...")
    tx = await router.addLiquidityETH(token,
        amount, // amountTokenDesired
        amount, // amountTokenMin
        amountETH, // amountETHMin
        owner, // to
        Date.now() + 600, // deadline
        { value: amountETH } // ETH
    )
    await tx.wait()
    console.log("✅Liquidity added.")
}

We define the amount of both tokens & ETH to add liquidity.

Remember that there are no decimals in Solidity. When you send 1 WETH to someone, you're essentially sending this instruction to the WETH contract: "Hello! I'm 0x...0, and this signed transaction authorizes moving 1000000000000000000 WETH from me to 0x...1."

Notice that enormous number? That's 1 WETH represented as 1 * 10 ** 18 or 1 followed by 18 zeros. Always remember this when dealing with tokens and their decimals. To improve the robustness of the scripts i always fetch the token's decimals dynamically from the contract at runtime, which helps avoid unpleasant surprises that I encountered in my journey (see the call to token.decimals() under attachContracts()).

We then define the approve call. The deployer account is requesting the contract address to approve the router to move tokens on its behalf, which is necessary for how the ERC20 approval works. When a contract needs to move tokens from another account, it must be authorized by the token's owner.

Here's a useful tip: If you send an approve transaction without waiting for its confirmation and then try to addLiquidity, the call will fail because the current chain state doesn't include your approval yet. To "resolve" this, you can override the gas value and nonce of the addLiquidity call. Ethers will calculate the gas value automatically (and will fail) if you don't override these fields. If you do override them, you can send the call just after the approve and it can get mined just after the approve call. Remember to do nonce + 1

However, there's generally no urgency to execute these actions in a single block. It's perfectly fine to follow the "workspace" approach: wait for the approval to be confirmed and then send the addLiquidity call.