T12 · Testing and Deployment

A Real-World Problem

You write a contract that accepts a stablecoin deposit, puts it into a lending protocol, and gives the user a receipt token.

You test carefully: a fake token, a fake lending protocol, 34 test cases, 97% coverage, all green.

You deploy to mainnet. The first real transaction reverts.

After an afternoon of investigation, you learn that this real stablecoin rejects a second approval when an existing allowance is nonzero. Your fake token did not behave that way because you implemented the standard, while the real token does not follow it exactly (the class of traps from T9).

You fix it and redeploy. The second transaction reverts. This time the real lending protocol has a minimum deposit for this asset, below which it rejects deposits. Your fake protocol had no such rule.

After your third deployment comes the hardest discovery: the contract’s administrator authority still belongs to the temporary address used by your deployment script. You wrote the transfer step, but nothing verified that it succeeded.

These problems share a cause:

They are not errors in your code. They are errors in your assumptions about the world, and your tests were built from those same assumptions.

97% coverage proves that your code ran. It does not prove any assumption true.

So how do you test against the real world instead of the world you imagined?

Thought Experiment

Think of prelaunch preparation as flight training, with four levels.

Level one: work it out on paper. Given wind speed, weight, and runway length, calculate the takeoff distance. Fast and cheap, it checks your formula. It cannot verify where those numbers came from. Use the wrong wind speed and a correct calculation still ends badly.

Level two: fly in a simulator. Build the airplane, runway, and tower, then run the whole procedure. You can now find problems between components, such as flaps failing after the landing gear retracts. But you built the simulated runway; it lacks potholes on the real one.

Level three: bring the actual airport into the simulator. Instead of building your own runway, import the layout, terrain, and navigation equipment of a real airport and fly there.

This is the heart of the chapter. Your code still runs locally, but it interacts with real current state: real tokens, protocols, parameters, and quirks. All three opening problems become visible here when their relevant steps run.

Level four: fly once for real, but carry sandbags. Rehearse the entire deployment flow in an environment without real money, including deployment, verification, and authority transfer.

The four levels have clear jobs:

• The first two validate your logic.
• The third validates your assumptions.
• The fourth validates your process.

These are different kinds of failure. No single method covers them all.

One more point matters more than any level:

Every entry point to a contract is public. Therefore, whether it rejects correctly matters more than whether it executes correctly.

There is one expected successful path, and you will test it. There are dozens of paths that must be rejected. Omit one and anyone can call that opening directly.

Your Decision

Your contract interacts with a real protocol. How do you test before launch?

What Happens

The four options are not a ranking. They cover two independent dimensions:

The key sentence hidden in the table:

Coverage measures how much of your code executed, not how many assumptions were tested.

A 100%-coverage suite built entirely on mocks may know nothing about real behavior. A single path running against real state may cover only 20% of branches but prevent a loss. The answer is to assign each layer a job:

• Use mocks for logic and rejection paths because they are fast enough for many cases.
• Use real state for integration because only it tests assumptions.
• Rehearse the complete deployment process because deployment is code few people test.

One further implication deserves its own line: the rejection case you never wrote is the public entry point someone else will call.

Build a Model

A Launch Pipeline

Notice the first step: write failure cases before success cases. This is about sequence, not style. After writing success cases, people often feel finished.

Rejection Checklist: One Test per Constraint

Open the contract and list every place it rejects a condition. Give each its own test.

The last row is special: write a malicious contract specifically as a test tool. Its sole job is to attempt something forbidden when called back. T28 covers the full reentrancy model, but the test belongs here.

Two easily missed points:

1. Assert the intended rejection, not just any error. Check the specific error type or message. Otherwise, a test remains green when the contract fails for an unrelated reason; false-green tests are common.
2. Check that state stayed unchanged. A revert should undo every state change in the transaction. An extra assertion on critical state can catch subtle mistakes.

Testing Real State: Three Essentials

First, pin the block number. When pulling state from a real network, specify a block in configuration. Otherwise, tests depend on live state that changes every few seconds. A test that was green today turns red next week, and you can spend days debugging a problem outside your code.

Second, prepare identity and balances. Your test account has no funds in real state. There are two approaches:

• Impersonate a real address holding much of the target asset. Most test frameworks can “send a transaction as any address.”
• Write storage directly to give yourself a balance. It is faster but requires knowing the balance slot (see the storage layout in T8).

Third, assert real outcomes, not merely the absence of an error. “The transaction did not revert” tells you little. Assert how your balance changed, which receipt tokens you received, and what the protocol’s accounting became.

A complete integration test looks like this:

1. Import state from a real network at a fixed block
2. Deploy your contract
3. Give the test account real assets in the local environment
4. Record all relevant pre-interaction balances and state
5. Call your contract through the full business path
6. Assert your balance, counterparty balance, receipt quantity, and protocol accounting separately
7. Run the reverse path (withdraw or redeem) and assert that you return to the start

Step 7 is easiest to skip and often where the problem hides. Being able to deposit does not mean being able to withdraw. Only trying it proves that path.

Fuzzing and Invariants: Executable “For Every Input” Claims

An ordinary test says “for this input, expect that output.” A randomized test reverses the question: for any input, a property must always hold.

These properties fit many contracts holding funds:

Assets actually held by the contract  ≥  sum of all user accounting balances
Sum of all holder balances             =  total supply
After any sequence of operations, an account can withdraw no more than it deposited
A “deposit then immediately withdraw” sequence is no better than doing nothing
A parameter reserved for the administrator remains unchanged after 10,000 random calls

The last is underrated: point a random caller at every public entry point for ten thousand calls, then check the invariant. It is cheap and often finds sequences you never considered.

Two practical details:

• Make failures reproducible. Record the seed and input sequence that caused the failure, then turn them into an ordinary permanent test.
• Define invariant scope carefully. An invariant about contract balance and accounting may be affected by direct transfers that bypass your entry points. Adjust the property or acknowledge a real defect.

Deployment Is Code That Few People Test

Deployment scripts may be the project’s only code that runs once, cannot be corrected afterward, and has no tests. The third opening problem occurred here.

A sound deployment script must do the following:

The third row is most important. The last part of the deployment script should be assertions, not “deployment complete”:

assert contract owner == configured multisig address
assert contract admin != deployer address
assert critical parameters == configured values
assert contract is paused (if launch begins paused)
assert external dependency address == configured address, and code exists at that address

The final check is easy to miss: an external address you supplied may contain no contract on this chain. Deployment accepts it quietly, and the first user transaction fails later.

One more process rule: rehearse the deployment script against local real-state tests first. Run the same configuration and script through deployment and assertions on imported real state. That can catch the three most expensive errors—configuration, addresses, and authority—before spending money.

What It Is Called

Hands-on

<your framework's fork flag> --fork-url <your archive RPC URL> --fork-block-number <a chosen block number>

Method one: impersonate a holder
  Find a real address with a large amount of your target token
  Use your framework's ability to simulate transactions from any address
  Transfer some funds to your test account

Method two: write storage directly
  Locate the storage slot for the balance mapping (T8 explained the layout)
  Use your framework's ability to write any storage slot

Case 1: call with amount 0; assert the intended rejection and unchanged state
Case 2: call without an allowance; assert the intended rejection
Case 3: call an administrative function as a nonadministrator; assert the intended rejection

Open the contract and count every “reject when condition is not met” rule.
Count tests that assert rejection.
The two counts should be close.

Assets actually held by the contract  ≥  sum of all user accounting balances

AI Lab

Step one:
Here is my contract source. Generate a test suite for it. First list every condition that
must cause rejection and give each a test asserting rejection. Then write success-path tests.
Explain what each case checks.

Step two:
Compare the tests you just wrote against my contract line by line in a table.
For every require, revert, or permission check, which test covers it?
List checks with no corresponding test separately.

Step three:
This contract integrates with a real external protocol, but my tests use a mock.
Which classes of difference between mock and reality could make tests pass but mainnet fail?
Give one concrete example per class and explain how to verify it on a fork.

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check