testkit-backend: Add support for testing driver in browser

[bigmontz]

The initial implementation of the testkit-backend is NodeJS only which is not an issue for the time being. However, It starts to be problematic with new features being implemented test driven using testkit as the source of tests. First, the time for run all the suite increased a lot with the number of tests added and the need of keeping the some integration tests to not let browser uncovered. Second, the driver running in browser was not being tested with the same rigour as in Nodejs.

The following changes were done with the intent to support testkit tests in Browser.

Refactoring

The logic of reading and writing in the socket, call the handlers and parse the messages were mixed in the Backend class. This makes difficult to add different protocols, channel implementation or controllers to the backend.

The goal of this change is separate this three concerns in Channel, Controller and Protocol with the Backend class as the glue between these concepts. New implementations of the Controller could enable this backend to test the driver running in the browser without have to change the logic of parsing the messages between testkit and testkit-backend, for instance.

Supporting Browser

The first step for supporting testkit in browser was creating a web socket server to redirect the requests to a client. RemoteController is the class responsible for it, it acts like a proxy redirecting the requests and responses. In the other side, WebSocketChannel is responsible for managing the messages exchanges between browser-backend and nodejs-backend in the browser side.

The main function glued everything together using env variables for selecting the correct channel and controller.

A bit more of structure had to be taking in place for bundle testkit for running in browser. The bundle is supported by rollup and defined in rollup.config.js, this runs during the build and the outcome is stored in public/index.js. The following env variables are defined during the browser build to enforce the correct configuration:

• TEST_ENVIRONMENT = "LOCAL"
• CHANNEL_TYPE = "WEBSOCKET"
• BACKEND_PORT = WEB_SERVER_PORT (or 8000 if nothing is set in WEB_SERVER_PORT)

The last thing done during the browser build process is done by some replacements done in the package.json, the ./src/controller/remote.js and ./src/channel/socket.js are replaced by their interfaces since the some modules used in this files are really tricky to support in browser and they are not need at browser.

After we have the browser bundle done, we need to server it. It is done by the RemoteController as well.

At this point, you can run TEST_ENVIRONMENT=REMOTE npm run start-testkit-backend and open your favorite browser in localhost:8000 for running testkit tests in browser.

Glue everything in Testkit

Last but not least, the testkit scripts were adapt to use the environment TEST_DRIVER_BROWSER to decide if the tests should be run in browser and in nodejs. Integration tests were segregated for running only the ones needed for the environment under tests.

backend.py is responsible for configuring correctly the backend using the env-variables and also for starting a headless browser with the browser-backend url.

IMPORTANTE NOTE

This version doesn't support TLS_TESTS and STUB_TESTS since the mock servers doesn't support websocket yet

[robsdedude]

Quite a few comments. None of them are a deal-breaker. Mainly typos and question.

Great PR!!!

🚀