Why Hardhat testing setup in Blockchain / Solidity? - Purpose & Use Cases

The Big Idea

What if you could test your blockchain code instantly and never miss a bug again?

The Scenario

Imagine you want to build a blockchain app and test your smart contracts by manually deploying them every time you make a change. You write scripts to deploy, then manually check if everything works as expected.

The Problem

This manual way is slow and tiring. Every small change means redeploying and checking again. It's easy to miss bugs or make mistakes because you don't have a quick, repeatable way to test your contracts.

The Solution

Hardhat testing setup automates this process. It lets you write tests that run quickly and repeatedly on a local blockchain. You can catch errors early and be confident your contracts work before deploying live.

Before vs After

✗ Before

node deploy.js
// Then manually check contract behavior

✓ After

npx hardhat test
// Runs all tests automatically on local blockchain

What It Enables

It enables fast, reliable, and automated testing of smart contracts, saving time and reducing costly mistakes.

Real Life Example

A developer building a decentralized voting app can quickly test vote counting and permission rules locally with Hardhat tests before going live.

Key Takeaways

Manual contract testing is slow and error-prone.

Hardhat testing automates and speeds up this process.

Automated tests help catch bugs early and improve confidence.

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