Browser Conversion Tests

[jalextowle]

Overview

This pull request introduces a large addition to 0x-mesh's testing infrastructure. Tests were added that can effectively test the Go --> Typescript interface that is used to send data to Typescript code that would like to interact with a browser based mesh node. This interface was previously a source of lots of bugs and would have been difficult to maintain with manual code review alone.

Architecture

A new framework had to be created to test this interface properly. The crux of the issue in this test is that values must be converted to their javascript counterparts by Go code in a Wasm binary and then these values should be processed by real Javascript (or in this case Typescript) code. To accomplish this behavior, a new Wasm binary was created, and this binary is embedded in a testing script written in Typescript and then served to a browser that is running in a go-routine of another Go file that serves as the entry-point to the test. The next sections will more clearly outline the role of each component of the test.

Entry Point

The entry into these conversion tests is the file browser/go/conversion-test/conversion_test.go. This file has three primary responsibilities: register test cases; serve the bundled test logic; and scrape the logs created by the bundled test script to identify test passes and failures (and missing results).

Registration of test cases is actually very straightforward. Test results are reported by the bundled test script in the form of console logs. These logs have a format of $description: true, where true indicates that the test passed. It is currently expected that these logs will be emitted in a particular order, so the test cases are registered in a slice called testCases. The Go code that handles emitted logs from the headless browser will just iterate over the list of testCases and verify that there is a log that matches every entry of testCases. Some features were implemented that will identify some unexpected logs (we don't want to wait forever, so logs that come very late and aren't expected will not be identified). Additionally, all of the registration logic in this file is structured in such a way that most of the boilerplate writing can be avoided. If many more of these tests need to be written in the future, code generation could hypothetically create these registration functions from reading the typescript conversion test implementation (manual generation of tests should be totally sufficient for the foreseeable future).

Typescript Conversion Test

Because of the way that Wasm currently works in the browser, the Typescript code in the bundle needs to control most of the testing inside of the browser. This code is responsible for instantiating a WebAssembly module that will execute the Wasm buffer and for verifying the results of calling test functions exposed by the Wasm code. The Wasm boilerplate is very similar to the implementation of integration-tests/browser/src/index.ts. When result are tested, logs are emitted that indicate whether or not an individual test passed or failed. There is a 1:1 correspondence between the logging calls in this file and the registration calls in the "entry point."

Wasm Binary

The Wasm binary is responsible for providing functions that the Typescript Conversion test can use to receive data from Wasm. As of right now, all of these functions simply return js.Value conversions of all of the types that have JSValue methods; however, this will not necessarily be the case in the future.

[albrow]

Honestly, I'm very impressed with this approach overall. It's clear you put a lot of thought and effort into it. There are a few small things I think we can improve.

[albrow]

Approved with one small suggestion.