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.

Practice

1.

What is the main purpose of an assertion in blockchain smart contract testing?

easy

A. To optimize the contract's gas usage

B. To log information without affecting execution

C. To deploy the contract to the blockchain

D. To check if a condition is true and stop execution if false

Solution

1. Step 1: Understand assertion role

   Assertions verify conditions during execution to ensure correctness.

2. Step 2: Identify assertion effect

   If the condition is false, assertions stop execution and revert changes to prevent errors.

3. Final Answer:

   To check if a condition is true and stop execution if false -> Option D

4. Quick Check:

   Assertions stop execution on false condition [OK]

Hint: Assertions stop code if condition fails, preventing errors [OK]

Common Mistakes:

• Thinking assertions only log info without stopping
• Confusing assertions with deployment steps
• Assuming assertions optimize gas usage

2.

Which of the following is the correct syntax for an assertion in Solidity?

?

easy

A. assert: balance >= amount;

B. assert(balance >= amount);

C. assert(balance < amount);

D. assert(balance = amount);

Solution

1. Step 1: Recall Solidity assertion syntax

   Assertions use the function-like syntax: assert(condition);

2. Step 2: Check condition correctness

   Condition should be a boolean expression, here balance >= amount is valid.

3. Final Answer:

   assert(balance >= amount); -> Option B

4. Quick Check:

   assert(condition) uses parentheses and semicolon [OK]

Hint: Assertions use assert(condition); with parentheses and semicolon [OK]

Common Mistakes:

• Using colon instead of parentheses
• Using assignment (=) instead of comparison (>=)
• Writing incorrect comparison operators

3.

Consider this Solidity code snippet:

uint balance = 100;
uint amount = 150;
assert(balance >= amount);

What will happen when this code runs?

medium

A. Execution continues normally

B. balance is updated to amount

C. Execution stops and reverts due to failed assertion

D. Compilation error due to invalid assertion

Solution

1. Step 1: Evaluate assertion condition

   balance is 100, amount is 150, so balance >= amount is false.

2. Step 2: Understand assertion behavior on false

   Assertion fails, so execution stops and reverts all changes.

3. Final Answer:

   Execution stops and reverts due to failed assertion -> Option C

4. Quick Check:

   False assertion stops execution [OK]

Hint: False assertion stops execution and reverts changes [OK]

Common Mistakes:

• Assuming code continues after failed assertion
• Thinking assertion causes compile error
• Believing balance changes automatically

4.

Identify the error in this Solidity assertion statement:

assert(balance = amount);

medium

A. Using assignment operator instead of comparison

B. Missing semicolon at the end

C. Incorrect function name, should be require()

D. balance and amount are undefined

Solution

1. Step 1: Analyze operator usage

   The single equals sign (=) assigns value, not compares values.

2. Step 2: Correct operator for assertion

   Assertions require comparison operators like == or >= to check conditions.

3. Final Answer:

   Using assignment operator instead of comparison -> Option A

4. Quick Check:

   Use '==' for comparison in assertions [OK]

Hint: Use '==' for comparison, not '=' assignment in assertions [OK]

Common Mistakes:

• Confusing '=' with '==' in conditions
• Thinking require() must replace assert() always
• Ignoring missing semicolon (which is present here)

5.

You want to assert that a user's balance is positive and provide a clear error message if not. Which assertion pattern is best?

?

hard

A. require(balance > 0, "Balance must be positive");

B. assert(balance > 0, "Balance must be positive");

C. assert(balance > 0);

D. if(balance <= 0) revert("Balance must be positive");

Solution

1. Step 1: Understand assertion vs require

   In Solidity, assert is for internal errors without messages; require allows error messages.

2. Step 2: Choose assertion with message

   require(condition, message) is best to check user input and show clear error.

3. Final Answer:

   require(balance > 0, "Balance must be positive"); -> Option A

4. Quick Check:

   Use require() for checks with error messages [OK]

Hint: Use require() to assert with clear error messages [OK]

Common Mistakes:

• Using assert() with message (not supported)
• Ignoring error messages in assertions
• Using if + revert instead of require() unnecessarily