feature: E2E real wallet data using esbuild #193

gbarkhatov · 2024-10-02T16:42:21Z

Added real wallet E2E tests

Wallets are generated via real mnemonic. Both mainnet/signet and taproot/native segwit
Since window.btcwallet is something we need to inject, and we do want our transactions to be real, we have to build our wallets with all the necessary bitcoin libs. We do it using esbuild
The only mocking part is the initial UTXOs and POST requests. I.e. under the hood real BTC signatures are happening
By default, Playwright will use the .env.local that you use. If you want to use a specific mainnet and signet env variables, you need to create .env.mainnet and .env.signet.
You can use whatever wallets you want in your tests, but some of them require the specific ones. For example, in case of balance and address test, we can connect both signet and mainnet wallets and check the stuff. But anything with the signing involved will require specific env variables. You cannot use mainnet env variables with global parameters expecting X mainnet BTC Tip height on signet wallet. Since signet tip height is going to be differentSostaking, unbonding, withdrawaluse a set of mapping and test required network wallets only. That's because in our app we usesrc/app/context/mempool/BtcHeightProvider.tsxwhich will giveXwhile wallet mempool endpoint might giveYdepending on theenv` variables.

Besides reviewing the code I expect you run the instructions in Readme.md:

npm i <- install the dependencies
npx playwright install <- this is important
npm run test:e2e <- for your .env.local or
npm run test:e2e:full <- for your .env.mainnet and .env.signet

Added an E2E section in Readme.md

Video: https://youtu.be/jppgJa9L6gM

Closes:

Partly closes, so the PR is not even bigger:

E2E Text constants #136

gbarkhatov · 2024-10-07T12:55:58Z

@totraev @jrwbabylonlab @jeremy-babylonlabs network is mocked, tests are working with wifi turned off

jrwbabylonlab · 2024-10-09T02:02:30Z

README.md

+### Environment Configuration
+The E2E tests can be run using either the .env.local file or the specific environment files .env.mainnet and .env.signet. These files should contain the following environment variables:
+
+- `NEXT_PUBLIC_NETWORK`: Specifies the BTC network environment (mainnet or signet).


Now that the E2E tests are using fully mocked data, do we still need all the environment setups across different env files? or maybe we can just create a single .env.test under the test directory for running the e2e test?

jrwbabylonlab · 2024-10-09T02:10:27Z

e2e/balanceAddress.spec.ts

+type AddressType = "taproot" | "nativeSegwit";
+
+// Determine the network from environment variable or default to 'mainnet'
+const network: Network =


can we not use existing network from the network.config.ts?

jrwbabylonlab · 2024-10-09T02:11:57Z

e2e/balanceAddress.spec.ts

+import { taprootSignetBalance } from "./mock/signet/wallet/taproot/utxos";
+
+type Network = "mainnet" | "signet";
+type AddressType = "taproot" | "nativeSegwit";


Duplicated with the types defined in WalletType

jrwbabylonlab · 2024-10-09T02:31:26Z

e2e/balanceAddress.spec.ts

-  });
+  // Iterate over each address type
+  for (const type of addressTypes) {
+    test.describe(`${type} address on ${network}`, () => {


I notice the network is controlled by the env passed in.
Why not we make a testcase set here and let the for loop to cover both networks instead of passing it via env?
So something like this:

const testCases: [AddressType, Network][] = [ ["taproot", "mainnet"], ["taproot", "signet"], ["nativeSegwit", "mainnet"], ["nativeSegwit", "signet"], ];

then we just do a testCase.forEach to loop through
What you think?

@jrwbabylonlab why we need test against multiple networks if everything is mocked?

Theoretically, it should be the same. The different network only matters if our code is performing BTC-specific operations. I’m not sure if our simple-staking implementation includes that (it shouldn’t), but it wouldn’t hurt to run it on multiple networks just to be safe.

jrwbabylonlab · 2024-10-09T02:38:12Z

e2e/helper/mockNetwork.ts

+    "**/tip/height**",
+    200,
+    isOnMainnet ? mainnetTipHeight : signetTipHeight,
+  );


maybe we can do this to simplify a bit

const mocks = [ { path: "**/healthcheck**", data: healthCheck }, { path: "**/v1/finality-providers**", data: finalityProviders }, { path: "**/fees/recommended**", data: network === "mainnet" ? mainnetFees : signetFees }, ... and others ]; mocks.forEach(async ({ path, data }) => { await interceptRequest(page, path, 200, data); });

jrwbabylonlab · 2024-10-09T02:39:51Z

e2e/balanceAddress.spec.ts

+
+      // Setup wallet connection before each test
+      test.beforeEach(async ({ page }) => {
+        await setupWalletConnection(page, network, type);


There’s no need to use two separate test.beforeEach calls. It's the same as a single beforeEach

jrwbabylonlab · 2024-10-09T02:48:23Z

e2e/types/wallet.ts

@@ -0,0 +1 @@
+export type WalletType = "taproot" | "nativeSegwit";


The name WalletType is a bit misleading tbh as this is actually address types that we currently support.

jrwbabylonlab · 2024-10-09T02:52:35Z

e2e/staking.spec.ts

+        const publicKeyNoCoord =
+          getPublicKeyNoCoord(publicKeyHex).toString("hex");
+
+        // Verify the local storage has the correct staking details


Instead of verifying if localStorage have the item, would it beteer to just inspect the delegation list html if it contain the newly created pending delegation?
IMO, the e2e test is a blockbox test that it doesn't need to know we are using localStorage. The only thing it care is click button, expect something to appear in UI

jrwbabylonlab · 2024-10-09T03:01:26Z

e2e/unbonding.spec.ts

+          updatedTX,
+        );
+        await setupWalletConnection(page, network, type);
+        await expect(page.getByText("Unbonded", { exact: true })).toBeVisible();


shall we locate to the exact tx id? otherwise if we expand the test to include multuple delegations, it won't work nicely

jrwbabylonlab

Approved with some comments, and below two actions:

could we add e2e into the pipeline?
could you set up the playwright config file that can help run the tests a few times? maybe 2-5 times is enough

gbarkhatov · 2024-10-09T06:35:27Z

could you set up the playwright config file that can help run the tests a few times? maybe 2-5 times is enough

@jrwbabylonlab This might be slow 😅

totraev

In general:

I think we should follow community standards and use fixtures over helper functions.
If we don't plan to use a separate repo for test wallet we need optimise current implementation. At the moment we recompile and rebuild wallet before each test(!):
test.beforeEach > setupWalletConnection > injectBTCWallet > build
Instead of using interceptRequest I'd suggest to run mock server and keep all mock there. It'll significantly simplify things

totraev · 2024-10-09T07:52:09Z

.gitignore

@@ -115,6 +115,8 @@ web_modules/
 .env.test.local
 .env.production.local
 .env.local
+.env.mainnet
+.env.signet



npm run test:e2e to run the test using the network in .env.local

When I run npm run test:e2e I see this. Is that expected behaviour?

totraev · 2024-10-09T08:02:12Z

e2e/balanceAddress.spec.ts

+const expectedAddresses: Record<AddressType, Record<Network, string>> = {
+  taproot: {
+    mainnet: TAPROOT_MAINNET_ADDRESS,
+    signet: TAPROOT_SIGNET_ADDRESS,
+  },
+  nativeSegwit: {
+    mainnet: NATIVE_SEGWIT_MAINNET_ADDRESS,
+    signet: NATIVE_SEGWIT_SIGNET_ADDRESS,
+  },
+};
+
+// Mappings for expected balances based on network and address type
+const expectedBalances: Record<AddressType, Record<Network, number>> = {
+  taproot: {
+    mainnet: taprootMainnetBalance,
+    signet: taprootSignetBalance,
+  },
+  nativeSegwit: {
+    mainnet: nativeSegwitMainnetBalance,
+    signet: nativeSegwitSignetBalance,
+  },
+};


We can move this logic together with current network to constants folder and return only taproot/nativeSegwit values depends on current network value:

const addresses = { mainnet: { taproot: 'address', nativeSegwit: 'address', }, signet: { taproot: 'address', nativeSegwit: 'address', } }[network];

totraev · 2024-10-09T08:04:56Z

e2e/balanceAddress.spec.ts

-  });
+  // Iterate over each address type
+  for (const type of addressTypes) {
+    test.describe(`${type} address on ${network}`, () => {


@jrwbabylonlab why we need test against multiple networks if everything is mocked?

totraev · 2024-10-09T08:08:35Z

e2e/balanceAddress.spec.ts

+      test(`should verify the ${type} address and balance on ${network}`, async ({
+        page,
+      }) => {
+        const expectedAddress = expectedAddresses[type][network];
+        const expectedBalance = expectedBalances[type][network];
+
+        // Perform address check
+        await checkAddress(page, expectedAddress);
+
+        // Perform balance check
+        await checkBalance(page, expectedBalance);
+      });


Test is pretty small, no need in additional wrapper. Weird to see test without expect expression

Suggested change

test(`should verify the ${type} address and balance on ${network}`, async ({

page,

}) => {

const expectedAddress = expectedAddresses[type][network];

const expectedBalance = expectedBalances[type][network];

// Perform address check

await checkAddress(page, expectedAddress);

// Perform balance check

await checkBalance(page, expectedBalance);

});

test(`should verify the ${type} address and balance on ${network}`, async ({

page,

}) => {

const expectedAddress = expectedAddresses[type][network];

const expectedBalance = expectedBalances[type][network];

// Perform address check

const address = await page.getByTestId("address").textContent();

expect(address).toBe(trim(expectedAddress));

// Perform balance check

const balanceText = await page.getByTestId("balance").textContent();

const balance = maxDecimals(extractNumericBalance(balanceText), 8);

expect(balance).toBe(satoshiToBtc(expectedBalance));

});

totraev · 2024-10-09T08:10:13Z

e2e/helper/injectBTCWallet.ts

+  try {
+    const walletPath = path.resolve(__dirname, "btcWallet.ts");
+
+    const result = await build({


I still think we should move it to a separate repo

gbarkhatov · 2024-10-15T09:41:03Z

Suggestion - finalize after the Tomo dual wallet onboarded

gbarkhatov · 2024-10-16T13:30:43Z

One thing we discussed with @jrwbabylonlab - we can skip the tests because of the UI, wallet, processes (staking, unbonding, withdrawal) and enable them as soon as the needed parts are working and settled. I.e. when we add working wallet solution we can enable wallet e2e tests

gbarkhatov · 2024-10-25T18:10:42Z

Converting this to draft until new changes are implemented related to Tomo wallet injectable and selectors

gbarkhatov requested review from vitsalis, totraev, jrwbabylonlab and jeremy-babylonlabs October 2, 2024 16:42

gbarkhatov mentioned this pull request Oct 2, 2024

feature: E2E real data #172

Closed

gbarkhatov marked this pull request as draft October 3, 2024 07:00

e2e real wallet data using esbuild

c4a5e87

gbarkhatov force-pushed the feature/e2e-esbuild branch from 694ea8d to c4a5e87 Compare October 7, 2024 12:54

gbarkhatov marked this pull request as ready for review October 7, 2024 12:54

gbarkhatov mentioned this pull request Oct 8, 2024

E2E Multi-browser + Mobile support #135

Open

jrwbabylonlab reviewed Oct 9, 2024

View reviewed changes

jrwbabylonlab approved these changes Oct 9, 2024

View reviewed changes

totraev requested changes Oct 9, 2024

View reviewed changes

totraev reviewed Oct 9, 2024

View reviewed changes

gbarkhatov mentioned this pull request Oct 16, 2024

E2E Text constants #136

Open

gbarkhatov marked this pull request as draft October 25, 2024 18:10

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feature: E2E real wallet data using esbuild #193

feature: E2E real wallet data using esbuild #193

gbarkhatov commented Oct 2, 2024

gbarkhatov commented Oct 7, 2024

jrwbabylonlab Oct 9, 2024 •

edited

Loading

jrwbabylonlab Oct 9, 2024

jrwbabylonlab Oct 9, 2024

jrwbabylonlab Oct 9, 2024

totraev Oct 9, 2024

jrwbabylonlab Oct 9, 2024

jrwbabylonlab Oct 9, 2024

jrwbabylonlab Oct 9, 2024

jrwbabylonlab Oct 9, 2024

jrwbabylonlab Oct 9, 2024

jrwbabylonlab Oct 9, 2024

jrwbabylonlab left a comment •

edited

Loading

gbarkhatov commented Oct 9, 2024 •

edited

Loading

totraev left a comment

totraev Oct 9, 2024

totraev Oct 9, 2024

totraev Oct 9, 2024

totraev Oct 9, 2024

totraev Oct 9, 2024

gbarkhatov commented Oct 15, 2024

gbarkhatov commented Oct 16, 2024

gbarkhatov commented Oct 25, 2024

		@@ -0,0 +1 @@
		export type WalletType = "taproot" \| "nativeSegwit";

feature: E2E real wallet data using esbuild #193

Are you sure you want to change the base?

feature: E2E real wallet data using esbuild #193

Conversation

gbarkhatov commented Oct 2, 2024

gbarkhatov commented Oct 7, 2024

jrwbabylonlab Oct 9, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jrwbabylonlab left a comment • edited Loading

Choose a reason for hiding this comment

gbarkhatov commented Oct 9, 2024 • edited Loading

totraev left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gbarkhatov commented Oct 15, 2024

gbarkhatov commented Oct 16, 2024

gbarkhatov commented Oct 25, 2024

jrwbabylonlab Oct 9, 2024 •

edited

Loading

jrwbabylonlab left a comment •

edited

Loading

gbarkhatov commented Oct 9, 2024 •

edited

Loading