List of e2e tests that cover cases not defined in BTP 1.1

[CyrusVorwald]

Overview

We have this BTP 1.1 Test Scenario document from awhile ago. It does not include changes from ICON Bridge.

We want to explicitly define and implement test cases to improve coverage of the ICON Bridge.

Rationale

Test coverage should reflect changes that were made in the pivot from BTP 1.1 to ICON Bridge.

Acceptance Criteria

• Git issue template for test cases
• See Git issues for newly defined test cases

[manishbista28]

The following includes a list of testing points not necessarily exclusive to e2e i.e. some of these could be tested with unit tests as well. They have still been included here to ensure that their scope is reviewed first.

1. Using incorrect address. Smart contract code expects a specific format of account address known only to the destination chain. Effect on providing a wrong format address should be checked. Preliminary tests shows that token transfers done from bsc to icon doesn't complete as expected. Some amount that was locked on bsc at the start of transfer does not get unlocked. Example destination address of wrong format: btp://0x613f17.icon/hx1691ead88bd5945a43c8a1da331ff6dd80e2936ee. (byte '1' is added at the start of hex address to make the address incorrect)
2. Fee Charges: The right amount of fee should be charged upon successful and failed transactions
3. Drain token supply: There is fixed supply of native tokens. Need to observe how transfers and refunds work when there is no supply of tokens on one side.
4. Variable Gas Price: Since variable gas pricing is a problem common in multiple chains and a known problem, having the problem replicated in test environment could mimic the production environment better, help as ascertain the quality of fix and identify other issues that might be waiting in production deployment.
5. Unit Test Cases:

• Zero address as recipient address (are mint and burn addresses)
• Zero amount token and fee charges
• Overflow and underflow integer values as amounts. Surely not practical amounts but to ensure they are handled
• BTPAddress parsing (e.g. count and position of delimiter '/' as it is used to parse out network address and destination hex address)
• RLPEncoding and Decoding. Sequence number (serialNo in solidity) is increased before encoding msg in sendServiceMessage(). So having encoding failed would possible mean a missing sequence number in event logs.

[manishbista28]

One of the test cases included was to drain token held by BTS Contract and observe behavior on transfers. The token has to be a fixed-supply token on both sides of chain.

• Transfer done from bsc to icon when BTS Contract in ICON does not have enough supply of token to provide to the destination_address. In this case, the amount initially locked in source side (bsc) remains locked. TransferReceived and TransferEnd event is not seen but BTP message can be seen transmitted both ways in relay logs.
• Similar test done the other way around i.e. icon->bsc works as expected i.e. TransferEnd event is logged with error response and locked amount gets unlocked.
• Transferring balance which is within the supply of BTSCore completes successfully and as expected.

Similar problem of amount being permanently locked on one direction (bsc->icon) and being reverted on the other was observed when using incorrect address (mentioned in 1)

Could you verify if the behavior is observed on your tests as well ?