-
Notifications
You must be signed in to change notification settings - Fork 270
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: e2e token contract can run in 2m with snapshots and test separa…
…tion. (#5526) Trying to run e2e tests makes one want to live a different life. They're slow (for root reasons that will eventually be addressed). e2e tests *ultimately* should be able to run in the "seconds" not "minutes" range. One day we may have a foundry like solution that could give sub-second state transitions, but that's a whole different ball game and won't happen soon. Developers should not be spending their time watching a minute of setup time in an e2e test before it even hits their code. Our CI is also horribly slow, and this PR could eventually help alleviate that. There are two main things of note in this PR. * It introduces a little snapshot engine for our e2e tests, that builds upon our ability to have our own anvil per test. * It splits our e2e_token_contract.test into 8 separate test files, and a `TokenContractTest` class to capture common behaviour/state. The second, is something we simply should be doing anyway. It's independent of the snapshot engine. People have got into the habit of rightward-drifting describe blocks into single e2e test files, but it's a bad pattern because jest cannot parallelise within a single test file. Better, for some of these larger e2e tests, would be to create a folder named after the test and to split them up, getting rid of the right-drifting describes, and having a nice flat test file. That's what this PR does with the token contract. Ignoring snapshotting, this get's running the e2e token contract tests time down from 10m to about 3m. That's with every test file still doing it's own ~1m of setup. # Snapshot Engine If you're a developer, and you're just wanting to run a part of your tests, the turnaround time of waiting 1 minute before you even hit your code is unacceptable. This PR introduces a small engine for reusing state snapshots within, and across test runs. To enable the snapshot engine, set e.g. `E2E_DATA_PATH=./data` before running tests. On the first run you'll notice the `data` folder is created, this contains snapshotted state. Subsequent runs leverage this to avoid having to do setup again. Within the `data` folder you'll see two folders: * `live` * `snapshots` The `live` folder contains subfolders scoped by test name, and reflects the currently executing state of that test. We generate snapshots from this live state, or restore the live state from snapshots. The `snapshots` folder contains a tree of folders that reflects the state snapshot tree. An example path here might be: ``` ./data/snapshots/3_accounts/e2e_token_contract/mint/snapshot ``` This shows 3 snapshots building on each other. * `3_accounts` added 3 accounts. * `e2e_token_contract` did some specifics to that test (deployed a token, bad account, etc). * `mint` minted some funds, specific to tests that needed minted funds. You can erase any level of the tree, and the next run will rebuild from that point. The `snapshot` function has the following signature. ```typescript public async snapshot<T>( name: string, apply: (context: SubsystemsContext) => Promise<T>, restore: (snapshotData: T, context: SubsystemsContext) => Promise<void> = () => Promise.resolve(), ); ``` * `name`: name of the snapshot, eg `3_accounts`. * `apply`: A function that actually does the state shift, e.g. deploying the accounts. It should return an object that is JSON serialisable that contains the necessary information to restore the state, e.g. the account addresses. * `restore`: A function that takes first argument the data that was returned by `apply`. You can use this to restore live objects within the test. Originally I had the concept of "pushing" and "popping" snapshots. But the popping aspect was a footgun, and would force use of the snapshot engine. Now a single test file can build a stack of snapshots, but can't pop. It's a simpler design and encourages creation of a new test file if that test file wants to start from a different state. i.e. you can imagine that a single test file sits at one of the nodes of the snapshot tree. If you have snapshot state, this gets running the contract tests down from 3m to 2m. However the real win is the turnaround time when you're iterating on a single test, which you can now run in sometimes as little as 7s.
- Loading branch information
1 parent
e4d2df6
commit b0037dd
Showing
35 changed files
with
2,035 additions
and
1,293 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,5 @@ | ||
import { type GrumpkinScalar } from '@aztec/foundation/fields'; | ||
import { GrumpkinScalar } from '@aztec/foundation/fields'; | ||
|
||
/** A type alias for private key which belongs to the scalar field of Grumpkin curve. */ | ||
export type GrumpkinPrivateKey = GrumpkinScalar; | ||
export const GrumpkinPrivateKey = GrumpkinScalar; |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.