Smart Contract Testing and Acceptance: What to Verify Before an Audit

A requirement matrix the buyer can review

Assume one approved ERC-20 asset and escrow agreements with active, disputed and terminal states. In this example, only the payer can authorize an ordinary release. Anyone can trigger the payer's refund for an undisputed agreement at or after its expiry. A resolver can settle a dispute but cannot redirect an undisputed agreement. Funding and ordinary release stop during a pause. Eligible refunds and dispute resolution remain available.

These are fictional product rules chosen to make the matrix concrete. They are not a recommendation for every escrow system. Define deadlines, authorized recipients and dispute behavior before turning them into tests.

ESC-06 needs to cover the failure forms admitted by the asset integration. ERC-20 requires callers to handle a false transfer result; assuming every unsuccessful token interaction reverts can leave a test plan incomplete. Support for other token behavior belongs in the asset specification, not in an unbounded claim to accept all ERC-20 tokens.

Attach actual result locations and statuses when testing the real candidate. The table records intended checks; a row whose evidence is pending has not passed acceptance.

Choose test methods for the rule being checked

Ethereum's testing documentation distinguishes unit, integration and property-based approaches. It also explains why code coverage and passing tests cannot guarantee that every input behaves correctly.

Use focused tests for a specific transition or permission check. Exercise components together when a payout depends on another contract or application. Generated inputs and operation sequences help explore arithmetic and state combinations, provided the campaign's allowed actions and assumptions are defined.

For ESC-07, write the unpaid-obligation calculation precisely. Include disputed obligations until they are validly settled. An asset balance greater than liabilities need not be an error: unsolicited token transfers can add assets without creating an agreement. An equality check would reject that situation even if no obligation was lost. This is a limitation of the proposed example, not a universal invariant for vaults, lending or fee-bearing products.

Keep the method linked to the requirement. A report listing a large number of fuzz runs says little about whether the generator ever opens disputes or exercises the expiry boundary. Ask which actors can call which operations and whether the model includes every relevant state.

External state must be reproducible

If a test depends on deployed contracts, record the network, block reference, external addresses and data assumptions. A fork-based test examines a selected state. It does not promise that a dependency will retain that behavior indefinitely, so identify what must be checked again near release.

An oracle-dependent product needs cases for its agreed freshness and failure rules. A cross-chain product needs a model of message delivery and replay behavior. Those cases are outside the escrow example, so its matrix should not be reused unchanged for either product.

Test the supported application path separately from contract permissions. A frontend can prevent a user from clicking release while the contract still permits a direct transaction. ESC-01 must check the contract rule without depending on the interface to enforce it.

Retain a release-specific evidence package

Package results so a receiving engineer can reproduce them without guessing which source revision or environment produced them.

Keep credentials out of shared logs and examples. Document how an authorized engineer obtains required access. Removing a secret should not remove the non-sensitive inputs needed to reproduce the run.

Reject a candidate when the evidence misses the requirement

Suppose all unit tests pass and the coverage report is high. The suite checks expiry before and after the deadline, but never exactly at it. The product specification says a refund becomes available at expiry. The implementation uses a strictly later comparison. The report cannot resolve that mismatch because the decisive input was never tested.

The acceptance action is to add the boundary case, correct whichever side conflicts with the approved product rule and rerun affected tests on the new revision. A green report from the old revision cannot accept the change. Keep the finding and its resolution linked to ESC-03.

An intentionally excluded behavior should receive an explicit limitation instead of a passing status. If the design supports only the approved settlement asset, accepting the project does not establish compatibility with a different token a user later supplies.

Handoff to independent review and deployment

Before independent review, agree the candidate version, audit scope and unresolved findings. Provide architecture and privileged-role documentation alongside test results. The smart contract audit overview covers the broader review context. A security audit engagement needs its own scope and reviewer, including an explicit independence boundary where the development provider is also involved in review.

Development acceptance and an independent audit answer different questions. Acceptance checks the agreed delivery. Review can uncover issues outside the current tests. New fixes need tests and a defined review path. Formal verification, if commissioned, also depends on the model and properties being proved.

For implementation, test design or agreed remediation, use Pharos smart contract development with the requirement matrix attached. Once the candidate is accepted for release, carry its identity and limitations into the deployment runbook. The release approver should see the exact revision, any unresolved finding and the evidence attached to each acceptance condition.