System Test: add support for Web JS on soroban dapp test cases

[sreuland]

What problem does your feature solve?

e2e tests currently invoke the soroban js/ts code from node/typescript engine referred to in the tests as NODEJS, but don't invoke it from an actual Web browser engine yet, which would validate additional browser side and polyfill aspects of the packaged dist of js/ts.

What would you like to see?

The dapp feature test suite should provide config ability for including Web browser side invocation as a client test case.

Web browser tests use the soroban-js-client

Add 'JSWEB' as Client Tool options in the Gherkin feature definitions(dapp_develop.feature):

  Examples: 
        | Tool         | ContractExampleSubPath | ContractName                  | ContractCompiledFileName             |FunctionName  | Param1    | Result             |
        | JSWEB        | hello_world            | soroban-hello-world-contract  | soroban_hello_world_contract.wasm    | hello        | Aloha     | ["Hello","Aloha"]  |
        | CLI          | hello_world            | soroban-hello-world-contract  | soroban_hello_world_contract.wasm    | hello        | Aloha     | ["Hello","Aloha"]  |
        | JSWEB        | increment              | soroban-increment-contract    | soroban_increment_contract.wasm      | increment    |           | 1                  | 
        | CLI          | increment              | soroban-increment-contract    | soroban_increment_contract.wasm      | increment    |           | 1                  |

Figure out how the web browser test will run, which headless browser?
How should the browser load/run the test js code to invoke soroban-js-client, as a small react app and package.json dependency to js-soroban-client?

What alternatives are there?

[paulbellamy]

I'd suggest https://phantomjs.org/. It's been more reliable than selenium for me in the past.

[sreuland]

i'm tentatively grabbing this, but anyone else that's interested, feel free to take it.

[sreuland]

@Shaptic , is this notion of executing js-soroban-client from a headless browser worthwhile coverage? does it run aspects of js-soroban-client dist that node/tsx invocations will miss iike polyfill aspects? just trying to determine if the extra effort to get this is worth the coverage.

[Shaptic]

In my experience, the browser-based tests in the libraries themselves are occasionally useful when there are polyfill or bundling differences, yes. They use karma to run in headless browser instances, too.

I think the projected 5 points of work may be worthwhile here because it would avoid having downstream systems (e.g. Freighter, Laboratory) be our guinea pigs for browser builds (as it is today): we could catch issues earlier and not rely on fitting our library updates into their work streams.