In this track: Build, test and reason
advanced · 4 MIN READ

Test revert data

Check the failure schema and state outcome.

LET’S PICTURE IT

A rejected request should have the expected reason without partially applying the action.

SEE IT FOR YOURSELF
Follow a revert and decode its error dataStep 1 / 4
Follow a revert and decode its error dataRequested actionTransfer 100 raw unitsExample inputsAvailable balance40 raw unitsCheck the ruleA deliberately failing local scenario, not a live transactionCondition fails100 > 40Request rejectedRollbackNo successful transferConsumed gas still mattersTop-level failure and a caught nested failure have different contextsError selector0x08c379a04 bytesMessage tailNot enough tokensDynamic string encodingCustom errors and Panic use different selectors and schemasDecoded messageNot enough tokensA diagnostic clueFurther evidenceCaller and code pathRelevant stateError bytes can be constructed by code; decoding is not authentication

This fictional call requests a transfer of one hundred raw units while the relevant balance is forty.

Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.

Choose the intended failure

Use an unrelated account calling PracticeCounter.increment. The expected custom error is NotOwner(address), with that account as the argument.

Check bytes or decoded fields

A runner can match the error selector and encoded caller or decode under the known error ABI. Avoid matching only a vague text fragment if exact structure matters.

Assert rollback

Count should remain at its previous value. A correctly shaped error payload alone does not prove that the surrounding application handled every effect consistently.

Preserve context in the test

Error bytes can be constructed or forwarded by code. The local test should establish which known contract and call produced the observed result.

Define the test

expected error: NotOwner(unrelatedAccount)
expected count after failure: previousCount
expected successful increment: absent

Test plans are framework-neutral unless labeled as complete Solidity or JavaScript. Use a local test environment and no real funds.

TURN UNDERSTANDING INTO PRACTICEOpen the Revert decoder →
QUICK CHECK · NO PRESSURE

Is a familiar error selector alone a complete state-outcome assertion?

Your progress stays in this browser.
Keep exploring the original referenceethereum.org ↗

Original explanations by EtherTools. Examples are educational and source-linked; this site is independent of the Ethereum Foundation. Our approach.