Description
Currently the dart2wasm compiler is tested purely by compiling Dart code to wasm and running them. While this works (and is the same as e.g. Dart VM's compiler used to be tested 10 years ago), it has some downsides.
For example: We spend considerable time to optimize size / performance of dart2wasm but those changes have no tests and we wouldn't notice easily if the optimizations don't trigger or for other reasons no longer apply.
Simply checking in the text representation (i.e. <app>.wat files) of dart2wasm compiled dart code (before and/or after running wasm-opt) isn't really an option, as such expectation files would break very often.
Having very fine grained unit tests is maybe also not what we want: We don't have an optimizing compiler, so we don't test optimization passes on an IR of a function, we may be more interested that certain Dart code ends up (together with binaryen) in certain wasm code.
In order to achieve this we could run the normal dart compile wasm and then have a reader that can read the resulting <app>.wasm file, dump the wasm code for one particular function and possibly signatures of targets called in that function and types used in that function. So the expectation files we'd get would be much more stable as they would've only information dumped for one partiular function instead of an entire app (which changes with any change to core library, compiler, binaryen, ...).