Event testing in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Event testing

Deploy Contract

↓

Trigger Function

↓

Emit Event

↓

Listen for Event

↓

Capture Event Data

↓

Assert Event Data in Test

↓

Test Pass or Fail

This flow shows how a blockchain contract emits an event during a function call, and how tests listen and check the event data.

Execution Sample

Blockchain / Solidity

contract MyContract {
  event ValueSet(uint256 value);
  uint256 public val;
  function setValue(uint256 _val) public {
    val = _val;
    emit ValueSet(_val);
  }
}

A simple contract that sets a value and emits an event with that value.

Execution Table

Step	Action	Event Emitted?	Event Data	Test Assertion
1	Deploy contract	No	-	-
2	Call setValue(42)	Yes	ValueSet(42)	Check event emitted with value 42
3	Test captures event	Yes	ValueSet(42)	Pass if event data matches 42
4	Call setValue(100)	Yes	ValueSet(100)	Check event emitted with value 100
5	Test captures event	Yes	ValueSet(100)	Pass if event data matches 100
6	No more calls	No	-	Test ends

💡 No more function calls, event testing complete

Variable Tracker

Variable	Start	After Step 2	After Step 4	Final
val	0	42	100	100
Last Event Data	-	ValueSet(42)	ValueSet(100)	ValueSet(100)

Key Moments - 2 Insights

Why do we check the event data after calling the function?

Because the event carries important info about what happened inside the contract, checking it confirms the function worked as expected (see execution_table rows 2 and 4).

What if the event is not emitted when expected?

The test will fail because it expects the event to be emitted with specific data (see execution_table rows 2 and 4 where event emission is Yes).

Visual Quiz - 3 Questions

Look at the execution table, what is the value of 'val' after step 4?

A 100

B 0

C 42

D Undefined

💡 Hint

Check variable_tracker row for 'val' after step 4

At which step does the event ValueSet(42) get emitted?

A Step 3

B Step 1

C Step 2

D Step 5

💡 Hint

See execution_table row where Event Emitted? is Yes and Event Data is ValueSet(42)

If the function setValue is never called, what happens to the event testing?

A Events are emitted with default values

B No events are emitted and tests fail

C Tests pass without events

D Contract crashes

💡 Hint

Refer to execution_table exit_note and event emission steps

Concept Snapshot

Event testing in blockchain:
- Deploy contract
- Call function that emits event
- Listen and capture event data
- Assert event data matches expected
- Test passes if event emitted correctly
- Test fails if event missing or data wrong

Full Transcript

Event testing in blockchain means checking that when a contract function runs, it emits the right event with correct data. The flow starts by deploying the contract, then calling a function that emits an event. Tests listen for this event and check its data. If the event data matches what is expected, the test passes. If the event is missing or data is wrong, the test fails. Variables like the stored value and last event data change as the function runs. This helps confirm the contract behaves as intended.

Practice

1.

What is the main purpose of event testing in blockchain smart contracts?

easy

A. To verify that the contract emits the correct events during execution

B. To check the contract's gas usage

C. To test the contract's user interface

D. To optimize the contract's storage

Solution

1. Step 1: Understand event testing purpose

   Event testing focuses on confirming that smart contracts emit the right signals (events) when certain actions happen.

2. Step 2: Compare options with event testing goal

   Only To verify that the contract emits the correct events during execution matches this purpose, as it talks about verifying emitted events.

3. Final Answer:

   To verify that the contract emits the correct events during execution -> Option A

4. Quick Check:

   Event testing = Verify emitted events [OK]

Hint: Event testing checks emitted signals, not gas or UI [OK]

Common Mistakes:

• Confusing event testing with gas optimization
• Thinking event testing checks UI elements
• Assuming event testing measures storage use

2.

Which of the following is the correct syntax to listen for an event named Transfer in a Solidity test using JavaScript?

contractInstance.Transfer({fromBlock: 0, toBlock: 'latest'}).???

easy

A. on

B. watch

C. emit

D. listen

Solution

1. Step 1: Recall event listening syntax in Solidity tests

   In older Solidity test frameworks, watch is used to listen for events on contract instances.

2. Step 2: Match options with correct method

   Only watch fits the syntax shown; on, emit, and listen are incorrect here.

3. Final Answer:

   watch -> Option B

4. Quick Check:

   Event listening method = watch [OK]

Hint: Use 'watch' to listen for events in Solidity JS tests [OK]

Common Mistakes:

• Using 'emit' which triggers events, not listens
• Confusing 'on' with event listening in other frameworks
• Using 'listen' which is not a Solidity test method

3.

Given this Solidity event and test snippet, what will be the output of console.log(events.length) after calling transfer() once?

event Transfer(address indexed from, address indexed to, uint amount);

// In test:
const events = await contractInstance.getPastEvents('Transfer', {fromBlock: 0, toBlock: 'latest'});
await contractInstance.transfer(receiver, 100);
console.log(events.length);

medium

A. undefined

B. 1

C. 0

D. 100

Solution

1. Step 1: Understand event fetching timing

   The getPastEvents call happens before transfer(), so it fetches events before the transfer.

2. Step 2: Analyze event count after transfer

   Since events are fetched before the transfer, events.length will be 0 because no Transfer event happened yet.

3. Final Answer:

   0 -> Option C

4. Quick Check:

   Events fetched before transfer = 0 [OK]

Hint: Fetch events after action to see new events [OK]

Common Mistakes:

• Assuming events array updates automatically
• Ignoring async order of calls
• Expecting event count before event occurs

4.

Identify the error in this test code snippet that listens for an event Approval:

contractInstance.Approval().watch((error, event) => {
  if (!error) {
    console.log('Approval event:', event);
  }
});

medium

A. Using watch instead of on

B. Using Approval() instead of Approval without parentheses

C. Incorrect callback function signature

D. Missing event filter parameters in the call

Solution

1. Step 1: Check event listening syntax

   The event constructor requires a filter object parameter (e.g., {fromBlock: 0}) to specify the event scope.

2. Step 2: Identify correct usage

   The correct syntax is contractInstance.Approval({fromBlock: 0}).watch(...); the code uses empty Approval().

3. Final Answer:

   Missing event filter parameters in the call -> Option D

4. Quick Check:

   Event filter params required [OK]

Hint: Include event filter parameters like {fromBlock: 0} [OK]

Common Mistakes:

• Omitting filter parameters in event call
• Confusing callback parameters
• Mixing event listening methods

5.

You want to test that a Deposit event is emitted only when the deposit amount is greater than zero. Which test approach correctly verifies this?

1. Call deposit(0) and check no event emitted
2. Call deposit(100) and check event emitted with amount 100
3. Call deposit(-50) and check event emitted
4. Call deposit(100) and check event emitted with amount 0

hard

A. Only steps 1 and 2 are correct test cases

B. All steps are correct to test event emission

C. Only step 3 is needed to test event emission

D. Only step 4 is correct to test event emission

Solution

1. Step 1: Understand event emission condition

   The event should emit only if deposit amount > 0, so deposit(0) should emit no event, deposit(100) should emit event with amount 100.

2. Step 2: Evaluate test steps

   Step 3 calls deposit(-50), which is invalid (negative deposit), so event emission is not expected. Step 4 expects event with amount 0, which contradicts the condition.

3. Final Answer:

   Only steps 1 and 2 are correct test cases -> Option A

4. Quick Check:

   Test event only for positive deposits [OK]

Hint: Test zero and positive amounts only for event emission [OK]

Common Mistakes:

• Testing negative amounts which are invalid
• Expecting event with zero amount
• Assuming all deposits emit events