Add tests for SDK

[gsteenkamp89]

closes ACX-2648

• uses anvil (prool) and vitest and msw
• forks 2 chains to closely
• runs in CI

E2E tests

• getQuote & executeQuote flow

NOTE:
Our use of a singleton does make unit tests slightly tricky (for the client initialization at least). Many properties and methods on our AcrossClient are private, thus not available for testing purposes.

QUESTION:
@dohaki @pxrl
Currently we are using MSW to mock api responses for quote, fees and chain info. In retrospect, this might not be necessary since our api is pretty open and inexpensive. We can turn off mocking with an env var, should we do this?

[changeset-bot]

⚠️ No Changeset found

Latest commit: 862138c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
toolkit-example	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 30, 2024 10:41am

[linear]

ACX-2648 Implement e2e tests

[pxrl]

NOTE: Our use of a singleton does make unit tests slightly tricky (for the client initialization at least). Many properties and methods on our AcrossClient are private, thus not available for testing purposes.

Is it worth changing these to protected so that they can be exposed via a another class that extends AcrossClient for test purposes? I've used that trick a bit in the relayer and sdk repos, at least.

QUESTION: @dohaki @pxrl Currently we are using MSW to mock api responses for quote, fees and chain info. In retrospect, this might not be necessary since our api is pretty open and inexpensive. We can turn off mocking with an env var, should we do this?

Given that this is classed as an e2e test then I can see value in querying the actual API. It's nice to verify that the implementation works in reality and not just in whatever we mocked 👍

[dohaki]

Awesome work! Just left a few questions.

[gsteenkamp89]

NOTE: Our use of a singleton does make unit tests slightly tricky (for the client initialization at least). Many properties and methods on our AcrossClient are private, thus not available for testing purposes.

Is it worth changing these to protected so that they can be exposed via a another class that extends AcrossClient for test purposes? I've used that trick a bit in the relayer and sdk repos, at least.

QUESTION: @dohaki @pxrl Currently we are using MSW to mock api responses for quote, fees and chain info. In retrospect, this might not be necessary since our api is pretty open and inexpensive. We can turn off mocking with an env var, should we do this?

Given that this is classed as an e2e test then I can see value in querying the actual API. It's nice to verify that the implementation works in reality and not just in whatever we mocked 👍

Okay I've disabled the mocks in CI, 👍