Hardhat testing setup in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Hardhat testing setup

Write test file

↓

Run 'npx hardhat test'

↓

Hardhat compiles contracts

↓

Hardhat deploys contracts to local network

↓

Tests execute functions

↓

Assertions check results

↓

Report pass/fail

↓

Exit

The flow shows writing tests, running Hardhat test command, compiling, deploying, executing tests, checking results, and reporting.

Execution Sample

Blockchain / Solidity

const { expect } = require("chai");
describe("SimpleStorage", function () {
  it("Should store and retrieve value", async function () {
    const SimpleStorage = await ethers.getContractFactory("SimpleStorage");
    const storage = await SimpleStorage.deploy();
    await storage.deployed();
    await storage.store(42);
    expect(await storage.retrieve()).to.equal(42);
  });
});

This test deploys a SimpleStorage contract, stores 42, and checks if retrieve returns 42.

Execution Table

Step	Action	Evaluation	Result
1	Load test file	Test code ready	Test suite defined
2	Run 'npx hardhat test'	Hardhat starts	Compiling contracts
3	Compile SimpleStorage.sol	Compilation success	Bytecode ready
4	Deploy SimpleStorage contract	Deployment success	Contract instance created
5	Call store(42)	Transaction mined	Value stored in contract
6	Call retrieve()	Returns stored value	42
7	Assert retrieved value == 42	Check passes	Test passes
8	Report results	All tests passed	Exit test run

💡 All tests passed, Hardhat test run completes successfully

Variable Tracker

Variable	Start	After Deploy	After store(42)	After retrieve()	Final
SimpleStorage	undefined	contract instance	contract instance	contract instance	contract instance
storedValue	undefined	undefined	42	42	42
retrievedValue	undefined	undefined	undefined	42	42

Key Moments - 3 Insights

Why do we need to deploy the contract before calling its functions?

Because the contract must exist on the local blockchain network to interact with it. See execution_table step 4 where deployment creates the contract instance.

What happens if the assertion fails?

The test run stops reporting failure at that step. In execution_table step 7, if the value was not 42, the test would fail here.

Why does Hardhat compile contracts before running tests?

Because tests interact with compiled bytecode. Without compilation (step 3), deployment and function calls cannot happen.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of storedValue after step 5?

A undefined

B 42

C 0

D null

💡 Hint

Check variable_tracker row for storedValue after 'After store(42)' column

At which step does Hardhat deploy the contract to the local network?

A Step 3

B Step 5

C Step 4

D Step 6

💡 Hint

See execution_table action column for deployment step

If the assertion in step 7 fails, what happens next?

A Test run reports failure and stops

B Test run continues with next test

C Contract redeploys automatically

D Stored value resets to 0

💡 Hint

Refer to key_moments explanation about assertion failure

Concept Snapshot

Hardhat testing setup:
- Write tests in JavaScript using Mocha and Chai
- Run tests with 'npx hardhat test'
- Hardhat compiles contracts before tests
- Contracts deploy to local network for testing
- Tests call contract functions and assert results
- Test results show pass/fail status

Full Transcript

This visual execution shows how Hardhat testing setup works step-by-step. First, you write a test file that uses Mocha and Chai to describe tests. When you run 'npx hardhat test', Hardhat compiles your smart contracts. Then it deploys the contracts to a local blockchain network. After deployment, the test calls contract functions like store and retrieve. The test checks if the retrieved value matches the expected value using assertions. If all assertions pass, the test run reports success and exits. Variables like storedValue change as functions execute. Key moments include understanding deployment before interaction, the importance of compilation, and what happens if assertions fail. The quizzes help confirm understanding of these steps and variable states. This setup helps developers test smart contracts safely and automatically before deploying to real networks.

Practice

1. What is the main purpose of using Hardhat testing setup in blockchain development?

easy

A. To create user interfaces for blockchain applications

B. To deploy smart contracts directly to the main Ethereum network

C. To write and run tests for smart contracts on a local blockchain

D. To mine real cryptocurrency coins

Solution

1. Step 1: Understand Hardhat testing role

   Hardhat testing setup is designed to help developers write and run tests for smart contracts safely.

2. Step 2: Identify the environment used

   Tests run on a local blockchain, which means no real money or main network is involved.

3. Final Answer:

   To write and run tests for smart contracts on a local blockchain -> Option C

4. Quick Check:

   Hardhat testing = local smart contract tests [OK]

Hint: Hardhat tests run locally, not on mainnet [OK]

Common Mistakes:

• Confusing testing with deployment to mainnet
• Thinking Hardhat mines real coins
• Assuming Hardhat builds user interfaces

2. Which of the following is the correct way to start a test suite in Hardhat using Mocha?

easy

A. test('MyContract', function() { ... })

B. describe('MyContract', function() { ... })

C. suite('MyContract', () => { ... })

D. context('MyContract', function() { ... })

Solution

1. Step 1: Recall Mocha test structure

   Hardhat uses Mocha for testing, which organizes tests with describe blocks.

2. Step 2: Identify correct syntax

   The describe function takes a string and a callback function to group tests.

3. Final Answer:

   describe('MyContract', function() { ... }) -> Option B

4. Quick Check:

   Mocha test suites use describe() [OK]

Hint: Use describe() to group tests in Hardhat [OK]

Common Mistakes:

• Using test() instead of describe() for suites
• Confusing suite() or context() with Mocha syntax
• Missing function keyword or arrow function

3. Given this Hardhat test snippet, what will be the output when running the test?

describe('SimpleTest', function() {
  it('should return true', async function() {
    const result = true;
    console.log(result);
    expect(result).to.equal(true);
  });
});

medium

A. true and test passes

B. false and test fails

C. undefined and test passes

D. Error: expect is not defined

Solution

1. Step 1: Analyze console output

   The code logs the variable result which is set to true, so console shows 'true'.

2. Step 2: Check assertion

   The test asserts result equals true, which is correct, so test passes.

3. Final Answer:

   true and test passes -> Option A

4. Quick Check:

   console.log(true) + expect(true) passes [OK]

Hint: Check console.log and expect values carefully [OK]

Common Mistakes:

• Assuming expect is undefined without import
• Confusing console output with test result
• Thinking test fails because of async function

4. Identify the error in this Hardhat test code snippet:

describe('Token', function() {
  it('should deploy contract', async () => {
    this.timeout(20000);
    const Token = await ethers.getContractFactory('Token');
    const token = await Token.deploy();
    await token.waitForDeployment();
    expect(token.address).to.be.a('string');
  });
});

medium

A. Missing import of ethers from Hardhat

B. deploy() should not be awaited

C. Incorrect assertion method for address type

D. Using arrow function in it() causes context loss

Solution

1. Step 1: Check function style in it()

   Using arrow functions in Mocha's it blocks can cause loss of this context, which Hardhat sometimes relies on.

2. Step 2: Verify other parts

   Imports and await usage are correct; assertion syntax is valid for checking string type.

3. Final Answer:

   Using arrow function in it() causes context loss -> Option D

4. Quick Check:

   Use function() not arrow in it() [OK]

Hint: Avoid arrow functions in it() blocks [OK]

Common Mistakes:

• Ignoring context loss with arrow functions
• Thinking deploy() is synchronous
• Assuming ethers import is automatic

5. You want to test a smart contract function that transfers tokens and emits an event. Which setup correctly tests the event emission using Hardhat and Chai?

hard

A. await expect(token.transfer(addr1.address, 100)).to.emit(token, 'Transfer').withArgs(owner.address, addr1.address, 100);

B. expect(token.transfer(addr1.address, 100)).to.emit('Transfer').withArgs(owner.address, addr1.address, 100);

C. await token.transfer(addr1.address, 100); expect(token).to.emit('Transfer');

D. token.transfer(addr1.address, 100); expect(token).to.emit(token, 'Transfer');

Solution

1. Step 1: Understand event testing syntax

   Hardhat with Chai uses await expect(transaction).to.emit(contract, eventName).withArgs(...) to test events.

2. Step 2: Check options for correct usage

   await expect(token.transfer(addr1.address, 100)).to.emit(token, 'Transfer').withArgs(owner.address, addr1.address, 100); correctly awaits the transaction and specifies contract and event with arguments.

3. Step 3: Identify errors in other options

   The other options either miss the await before expect, fail to specify the contract instance in to.emit(), or use incorrect syntax chaining.

4. Final Answer:

   await expect(token.transfer(addr1.address, 100)).to.emit(token, 'Transfer').withArgs(owner.address, addr1.address, 100); -> Option A

5. Quick Check:

   Use await expect(...).to.emit(contract, event) [OK]

Hint: Always await expect() when testing events [OK]

Common Mistakes:

• Forgetting to await the expect call
• Not specifying the contract in to.emit()
• Calling expect on transaction result instead of promise