Skip to content

Conversation

@johngrantuk
Copy link
Member

@johngrantuk johngrantuk commented Dec 9, 2025

Refactors V3 swap integration tests to use persisted test data for faster runs.

Changes:

  • New test suite (test/entities/swaps/v3/swap.integration.test.ts):
    Integration tests for V3 swaps covering:
  • Native input/output handling
  • Permit2 direct approval flows
  • Both GivenIn and GivenOut swap kinds
  • Conditional fork setup: only starts forks when saved test data is missing
  • Test data persistence: saves query outputs and call data to JSON for reuse

Test data file (test/entities/swaps/v3/swapTestData.json):

  • Stores serialized query outputs and call data
  • Enables tests to run without fork setup when data exists

Benefits

  • Faster test execution: skips fork setup and query calls when saved data exists
  • Deterministic comparisons: compares serialized call data against saved values
  • Maintains full integration coverage: still runs full assertions when data is missing
  • Better test isolation: uses snapshots for consistent test state

client: PublicWalletClient & TestActions;
snapshotPreApprove: Hex;
}> {
const fork = await startFork(test.anvilNetwork, jobId);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this might be where the current issues come from - at least locally it seems like the jobId isn't unique for each test. So we have multiple tests running in parallel reseting/altering state on the same fork which causes issues with nonces, etc. I think the same might also be happening in a single test file where different tests run in parallel and reset to snapshot. Using sequential should stop that.

Copy link
Member

@brunoguerios brunoguerios left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall I like the idea of relying on static pre-generated test data 👍
Old test structure is taking forever to run - is that because we're relying in older blockNumbers?
I think there's room to organize things a bit so it's a bit easier to follow, because in order to achieve the new structure a lot complexity was added 😅
Hopefully while refactoring tests for add/remove liquidity it will be easier to identify what's being reused and should be moved to some utils file/folder?
Something to consider is the approach used in balancer-maths where we separate testData generation and consumption in a more clear way.

Comment on lines 871 to 878
outputTest?: {
testExactOutAmount: boolean;
percentage: number;
};
inputTest?: {
testExactInAmount: boolean;
percentage: number;
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understood correctly, this is for allowing to config a tolerance on the test result, right?
How about we replace all this with something like percentageTolerance or something like that?
Being input or output is already specified on swapKind and being exact is a special case where percentageTolerance is zero, right?

@johngrantuk johngrantuk marked this pull request as ready for review December 18, 2025 12:13
Copy link
Member

@brunoguerios brunoguerios left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does look a lot better organized 👍
I'd say the improved efficiency should compensate for the increased complexity.
Hopefully this will finally solve our recurring issues with CI 🤞

);
}
if (
data.token.wrapped !== undefined &&
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will likely need to be refactored after merging main back to this working branch since wrapped was removed from Token

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants