Testing with ethers.js in Blockchain / Solidity - Time & Space Complexity

Time Complexity: Testing with ethers.js

O(n)

Understanding Time Complexity

When testing smart contracts with ethers.js, it's important to know how the time to run tests changes as the number of tests or contract calls grows.

We want to understand how the test execution time scales when we add more test cases or interact more with the blockchain.

Scenario Under Consideration

Analyze the time complexity of the following ethers.js test code snippet.

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

describe("SimpleContract", function () {
  it("should return correct value", async function () {
    const contract = await ethers.getContractFactory("SimpleContract").then(factory => factory.deploy());
    await contract.deployed();
    for (let i = 0; i < 100; i++) {
      const value = await contract.getValue(i);
      expect(value).to.equal(i * 2);
    }
  });
});
    

This code deploys a contract and calls a function 100 times in a loop, checking the returned value each time.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: The loop calling contract.getValue(i) 100 times.
• How many times: Exactly 100 times in this example, but this number can grow with test size.

How Execution Grows With Input

As the number of calls in the loop increases, the total test time grows roughly in direct proportion.

Input Size (n)	Approx. Operations
10	10 contract calls
100	100 contract calls
1000	1000 contract calls

Pattern observation: Doubling the number of calls roughly doubles the total execution time.

Final Time Complexity

Time Complexity: O(n)

This means the test time grows linearly with the number of contract calls in the loop.

Common Mistake

[X] Wrong: "Adding more calls inside the test loop won't affect test time much because calls are fast."

[OK] Correct: Each contract call involves communication with the blockchain simulator or network, which takes time. More calls add up and increase total test time linearly.

Interview Connect

Understanding how test execution time grows helps you write efficient tests and shows you can think about performance beyond just code correctness.

Self-Check

"What if we batch multiple calls into one contract function instead of calling individually? How would the time complexity change?"

Practice

1. What is the main purpose of using ethers.js in testing smart contracts?

easy

A. To create new blockchain networks

B. To design the user interface of a blockchain app

C. To mine new blocks on the blockchain

D. To interact with smart contracts and verify their behavior programmatically

Solution

1. Step 1: Understand ethers.js role

   ethers.js is a library that helps developers interact with Ethereum smart contracts in code.

2. Step 2: Identify testing purpose

   In testing, ethers.js lets you call contract functions and check if they behave as expected.

3. Final Answer:

   To interact with smart contracts and verify their behavior programmatically -> Option D

4. Quick Check:

   ethers.js tests contract behavior = A [OK]

Hint: Remember: ethers.js tests contracts by calling their functions [OK]

Common Mistakes:

• Confusing ethers.js with UI design tools
• Thinking ethers.js mines blocks
• Assuming ethers.js creates blockchains

2. Which of the following is the correct way to get a signer from a provider in ethers.js?

easy

A. const signer = provider.signer();

B. const signer = provider.getSigner();

C. const signer = provider.getsigner();

D. const signer = provider.sign();

Solution

1. Step 1: Recall ethers.js signer method

   The correct method to get a signer from a provider is getSigner() with capital S.

2. Step 2: Check method spelling and casing

   Options B, C, and D have incorrect method names or casing.

3. Final Answer:

   const signer = provider.getSigner(); -> Option B

4. Quick Check:

   Correct method is getSigner() = A [OK]

Hint: Method names are case-sensitive; use getSigner() exactly [OK]

Common Mistakes:

• Using wrong casing like signer() instead of getSigner()
• Misspelling method names
• Confusing signer with sign

3. Consider this ethers.js test code snippet:

const tx = await contract.setValue(42);
await tx.wait();
const value = await contract.getValue();
console.log(value);

What will be printed to the console?

medium

A. 42

B. undefined

C. Transaction hash

D. Error: contract.getValue is not a function

Solution

1. Step 1: Understand transaction and wait

   The code calls setValue(42) on the contract, then waits for the transaction to confirm with tx.wait().

2. Step 2: Retrieve stored value

   After confirmation, it calls getValue() which returns the stored value 42.

3. Final Answer:

   42 -> Option A

4. Quick Check:

   Confirmed setValue(42) then getValue() = 42 [OK]

Hint: Always wait for tx confirmation before reading updated state [OK]

Common Mistakes:

• Not awaiting tx.wait() before reading value
• Expecting transaction hash instead of value
• Assuming getValue() is undefined

4. You wrote this test code but it throws an error:

const tx = contract.setValue(10);
await tx.wait();

What is the likely cause of the error?

medium

A. Missing await before contract.setValue(10)

B. tx.wait() is not a function

C. contract.setValue does not exist

D. Provider is not connected

Solution

1. Step 1: Check async call to contract method

   contract.setValue(10) returns a Promise, so it must be awaited to get the transaction object.

2. Step 2: Identify missing await issue

   Without await, tx is a Promise, which does not have a wait() method, causing the error.

3. Final Answer:

   Missing await before contract.setValue(10) -> Option A

4. Quick Check:

   Await async call before tx.wait() = C [OK]

Hint: Always await contract calls returning transactions before wait() [OK]

Common Mistakes:

• Forgetting await before async contract calls
• Assuming tx is transaction without awaiting
• Not checking provider connection first

5. You want to test a smart contract function transfer(address to, uint amount) that emits an event Transfer. Which ethers.js testing approach correctly waits for the transaction and verifies the event was emitted?

hard

A. await contract.transfer(addr, 100);
expect(tx.events[0].event).to.equal('Transfer');

B. const receipt = await contract.transfer(addr, 100);
expect(receipt.events[0].event).to.equal('Transfer');

C. const tx = await contract.transfer(addr, 100);
const receipt = await tx.wait();
expect(receipt.events[0].event).to.equal('Transfer');

D. const tx = contract.transfer(addr, 100);
expect(tx.events[0].event).to.equal('Transfer');

Solution

1. Step 1: Await the transaction call

   Use await to get the transaction object from contract.transfer.

2. Step 2: Wait for transaction confirmation and get receipt

   Call tx.wait() to get the receipt which contains event logs.

3. Step 3: Verify event in receipt

   Check receipt.events[0].event equals 'Transfer' to confirm event emitted.

4. Final Answer:

   const tx = await contract.transfer(addr, 100); const receipt = await tx.wait(); expect(receipt.events[0].event).to.equal('Transfer'); -> Option C

5. Quick Check:

   Await tx, wait receipt, check event = D [OK]

Hint: Always await tx, then wait for receipt to check events [OK]

Common Mistakes:

• Not awaiting transaction before wait()
• Trying to access events on tx instead of receipt
• Ignoring event verification after transaction