RPC constants integration test "successfully fetches all constants for *net using ${rpc}" hard codes return values

[arvidj]

Description

The RPC constants integration test "successfully fetches all constants for {kathmandu,monday}net using ${rpc}" hard codes the return values for the RPC call to those returned in the given test network. This makes it hard to run this test against local sandboxed networks where the constants might vary.

Steps To Reproduce
Steps to reproduce the behavior:

1. Start a local sandboxed octez node with RPC endpoint http://localhost:8732 running protocol alpha
2. Run the integration tests, e.g. TEZOS_RPC_MONDAYNET=http://localhost:8732 RUN_MONDAYNET_WITH_SECRET_KEY=true npm run -w integration-tests test -- --reporters=default --reporters=jest-junit rpc-get-protocol-constants.spec.ts
3. It will fail.

Expected behavior

For example, the test might just check the schema of the constants when the test network is not the real mondaynet / kathmandunet.

Additional context

This is an issue in TeCI.

[hui-an-yang]

Hello @arvidj

Thanks for reaching out to us. I have looked into this and discussed it with the team and we still find it relevant in testing the current testnet(nairobinet) and mondaynet in their constant values. I also found that with your recent contribution of pr#2164, you can pass environment variables to make sandbox tests and skip testnet-specific tests. Below is an example. We'll appreciate if you could let us know if this has resolved the issue you created. Thank you:)

TEZOS_NETWORK_TYPE=sandbox TEZOS_RPC_MONDAYNET=http://localhost:8732 RUN_MONDAYNET_WITH_SECRET_KEY=true npm run -w integration-tests test -- --reporters=default --reporters=jest-junit rpc-get-protocol-constants.spec.ts

TEZOS_NETWORK_TYPE=sandbox TEZOS_RPC_NAIROBINET=http://localhost:8732 RUN_NAIROBINET_WITH_SECRET_KEY=true npm run -w integration-tests test -- --reporters=default --reporters=jest-junit rpc-get-protocol-constants.spec.ts

[arvidj]

Hi @hui-an-yang , thanks for reaching out to me. Indeed, it seems like this issue is now solved. Closing!