Making It Itself Prove

This board is real. It is `_update` from OpenZeppelin's `ERC20.sol`, pinned at a commit and hashed like every real board in this course, and it is the function you followed down to in week six when you traced one movement through three functions.

A test of a transfer is a statement about these thirty six lines, whoever wrote the token above them. Read them once more before the second test file arrives, because the assertions in that file are these lines said back in numbers.

Line 177 asks whether `from` is the zero address. If it is, line 179 grows the supply and this is a mint. If it is not, the `else` on line 180 reads a balance on 181 and reduces it on 187. Line 191 asks the same question at the other end.

Four lines write something, and which two of them run depends on which ends exist. Decide what an ordinary transfer between two holders touches before you scroll, because that is the list a test has to state.

Line 182 compares the balance read on 181 against the value, and line 183 refuses with a named error carrying three numbers. A refusal is behaviour like any other: on a given input it either happens or it does not.

A test that assumes a refusal proves nothing about it. Assuming is what the first file does everywhere, by never once asking for one. The second file asks, and you are two boards away from seeing what asking looks like.

Read a test the way you read a contract. What does it set up, what does it call, what does it assert. Lines 29 to 32 answer the first two questions and leave the third empty: a sender, a call, a closing brace.

It passes, and the name on line 29 says why. It did not revert. That is a real property and it is a very small one, because nothing in those four lines says what either balance was meant to become.

This board is not deployed code either, and belongs to no repository. It is the same token tested again, after a different request: write me a test that fails if a transfer moves anything other than the amount it was handed.

Two test functions rather than four, and both of them longer. Read the shape before the detail. Three numbers are read on lines 19 to 21, the call sits alone on line 24, and three assertions follow it.

Lines 19 to 21 do nothing to the contract. They read the sender's balance, the receiver's balance and the total supply into three local variables while the world is still untouched, and all three run before the call on line 24.

That is the whole mechanism. A property stated in numbers needs a before and an after, and the before has to be captured rather than assumed. Line 26 is about to subtract from one of these three.

Lines 26 to 28 say the sender is down by exactly thirty, the receiver is up by exactly thirty, and the supply is the number it was. Each is an `assertEq` against arithmetic done on a value captured before the call ran.

The first file said something about the receiver too, on line 37: it holds more than zero. Put that line beside line 27 here and suppose the token credits twenty nine where it debits thirty. One of the two carries a number, and one carries a direction.

Line 32 reads the sender's balance, line 35 declares that the next call must revert, and line 36 asks for one token more than the balance holds. If that call goes through instead, line 35 is what fails, and it fails loudly.

Line 38 then checks the balance is still the number line 32 captured. That is two statements about one refusal: that it happened at all, and that nothing moved on the way to it. Neither line would be here if the request had not named a failure.

A test has five parts and this file puts them on five lines. What it sets up, what it captures, what it calls, what it asserts about the numbers, and what it demands the contract refuse to do at all.

Tap each of the five lit lines in turn. That list is the reading you now do on any test file somebody hands you, in exactly the order you already read a contract, and a part that is missing is the thing worth asking about.

Ask for tests and you get tests. Ask for a test that fails if the sender is not down by exactly the amount, or the receiver not up by exactly the amount, or the supply not left alone, and you get lines 26 to 28.

Name the failure you want to see. Lines 187, 199 and 203 are what a transfer does here, so pointing a request at a file at a commit hands the machine, and you, the same three numbers to work from.

This file passes and the first one passes, and only one of them would have caught a wrong amount. That is a real result. Before the course ends, put an edge on it, because a green run is a claim like any other.

Say what these two tests settle and what they do not. Not what you hope about coverage, and not what you suspect about machines that write code. Only what these forty lines, having run once and passed, can honestly tell you.

Thirteen weeks ago you could not open a contract. Twenty eight checkpoints later you can read one cold, take apart a file nobody introduced, and work with a machine that writes Solidity faster than anyone can type it. That is the whole of what was promised.

Every board in the first four acts was real deployed code, fetched at a commit and hashed so it could not drift. The only boards that were not real are the ones this act told you were not real. That was the point.