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
This fictional call requests a transfer of one hundred raw units while the relevant balance is forty.
This fictional call requests a transfer of one hundred raw units while the relevant balance is forty.The contract rejects this request. State changes in the reverted call are rolled back, while work already consumed can still cost gas.A common Error(string) begins with selector 08c379a0. This example then encodes the message Not enough tokens.A decoder can recognize the supplied error shape. Identifying the true cause and source still needs the call context, code and state.
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.