Assertion patterns in Blockchain / Solidity - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ assertion

intermediate

Identify the correct assertion for checking event emission

In Solidity testing, which assertion correctly verifies that the Transfer event was emitted with the expected from and to addresses?

Blockchain / Solidity

event Transfer(address indexed from, address indexed to, uint256 value);

// Test snippet
// Assume 'tx' is the transaction receipt after calling a transfer function

A assert(tx.logs[0].event == 'Transfer' && tx.logs[0].args.from == sender && tx.logs[0].args.to == receiver);

B assertEvent(tx, 'Transfer', {from: sender, to: receiver});

C assert(tx.TransferEvent.from == sender && tx.TransferEvent.to == receiver);

D assert(tx.events.Transfer.from == sender && tx.events.Transfer.to == receiver);

💡 Hint

Look for the correct way to access event logs and their arguments in transaction receipts.

In Solidity testing frameworks like Truffle, event logs are accessed via tx.logs. Each log has an event name and args object with event parameters. Option A correctly checks the first log's event name and arguments.

❓ assertion

intermediate

Choose the assertion that correctly checks a revert reason

Which assertion pattern correctly verifies that a Solidity function call reverts with the reason 'Insufficient balance'?

Blockchain / Solidity

// Assume 'contractInstance' is the deployed contract
// and 'callFunction' is a function expected to revert

A await expectRevert(contractInstance.callFunction(), 'Insufficient balance');

B expect(contractInstance.callFunction()).to.be.revertedWith('Insufficient balance');

C assertRevert(contractInstance.callFunction(), 'Insufficient balance');

D assertThrows(contractInstance.callFunction(), 'Insufficient balance');

💡 Hint

Consider the syntax used by the Chai assertion library with Ethereum Waffle or Hardhat.

Option B uses the modern and widely adopted Chai matchers for Ethereum testing, which correctly assert that a promise is reverted with a specific reason string.

❓ Predict Output

advanced

What is the assertion outcome of this balance check?

Given the following Solidity test snippet, what will be the result of the assertion?

Blockchain / Solidity

const initialBalance = await token.balanceOf(user.address);
await token.transfer(receiver.address, 100);
const finalBalance = await token.balanceOf(user.address);
assert(finalBalance.eq(initialBalance.sub(100)));

A Fail - The user's balance increased by 100 tokens

B Fail - The user's balance did not change

C Pass - The user's balance decreased by 100 tokens

D Error - 'eq' is not a function on balance values

💡 Hint

Remember that token balances are BigNumber objects and support eq and sub methods.

The assertion checks that the final balance equals the initial balance minus 100 tokens, which is correct after a transfer of 100 tokens. The eq method compares BigNumber values properly.

🔧 Debug

advanced

Find the assertion mistake in this Solidity test

Identify the problem with the assertion in this Solidity test snippet:

Blockchain / Solidity

const result = contractInstance.someFunction();
assert(result === true, 'Function should return true');

A The assertion is correct and will pass if function returns true

B The assertion message is missing a semicolon

C The assertion should use 'assert.equal' instead of 'assert'

D The assertion uses strict equality on a Promise instead of awaited value

💡 Hint

Check if the function call is awaited before assertion.

The function call returns a Promise. The assertion compares the Promise object to true, which is always false. The correct approach is to await the Promise before asserting.

❓ framework

expert

Which assertion pattern best integrates with Hardhat's testing framework for checking emitted events with indexed parameters?

In Hardhat tests using ethers.js and Chai, which assertion pattern correctly verifies that the Approval event was emitted with the expected owner and spender addresses, considering that these parameters are indexed?

Blockchain / Solidity

// Assume 'tx' is the transaction response after calling approve

A await expect(tx).to.emit(contract, 'Approval').withArgs(owner, spender, amount);

B assertEvent(tx, 'Approval', {owner: owner, spender: spender, value: amount});

C expectEvent(tx, 'Approval', {owner: owner, spender: spender, value: amount});

D await expect(tx).to.emit(contract, 'Approval').withIndexedArgs(owner, spender, amount);

💡 Hint

Check the official Hardhat Chai matchers documentation for event assertions.

Option A uses Hardhat's Chai matchers correctly. The withArgs method works with indexed event parameters. Options B and C are not standard Hardhat assertions, and D uses a non-existent method.