Emscripten Test Suite

Emscripten has a comprehensive test suite, which covers virtually all Emscripten functionality. These tests are an excellent resource for developers as they provide practical examples of most features, and are known to pass on the main branch. In addition to correctness tests, there are also benchmarks that you can run.

This article explains how to run the test and benchmark suite, and provides an overview of what tests are available.

Setting up

To run the tests, you need an emscripten setup, as it will run emcc and other commands. See the developer’s guide for how best to do that.

Running tests

Run the test suite runner (test/runner) with --help to see the help message:

test/runner --help

The tests are divided into modes. You can run either an entire mode or an individual test, or use wildcards to run some tests in some modes. For example:

# run one test (in the default mode)
test/runner test_foo

# run a bunch of tests in one mode (here, all i64 tests in -O3)
test/runner core3.test_*i64*

# run all tests in a specific mode (here, wasm2gs -O1)
test/runner wasm2js1

The core test modes (defined at the bottom of test/test_core.py) let you run the tests in variety of different configurations and with different optimization flags. For example, wasm2js or wasm64. There are also non-core test suites, that run tests in more special manner (in particular, in those tests it is not possible to say “run the test with a different optimization flag” - that is what the core tests are for). The non-core test suites include

  • other: Non-core tests running in the shell.

  • browser: Tests that run in a browser.

  • sockets_node: Networking tests that run under node.

  • sockets_browser: Networking tests that run in a browser.

  • interactive: Browser tests that are not fully automated, and require user interaction (these should be automated eventually).

  • sanity: Tests for emscripten setting itself up. This modifies your .emscripten file temporarily.

  • benchmark: Runs benchmarks, measuring speed and code size.

The wildcards we mentioned above work for non-core test modes too, for example:

# run one browser test
test/runner browser.test_sdl_image

# run all SDL2 browser tests
test/runner browser.test_sdl2*

# run all browser tests
test/runner browser

Skipping Tests

An individual test can be skipped by passing the “skip:” prefix. E.g.

test/runner other skip:other.test_cmake

Wildcards can also be passed in skip, so

test/runner browser skip:browser.test_pthread_*

will run the whole browser suite except for all the pthread tests in it.

Exiting on first failure

Sometimes it is useful to be able to iteratively fix one test at a time. In this case the --failfast option can be used to exit the test runner after the first failure.

Note

This option only works with the serial test runner. For test suites that are normally run in parallel you can force them to run serially using -j1.

Once a test is fixed, you continue where you left off using --start-at option:

test/runner browser --start-at test_foo --failfast

Running a bunch of random tests

You can run a random subset of the test suite, using something like

test/runner random100

Replace 100 with another number as you prefer. This will run that number of random tests, and tell you the statistical likelihood of almost all the test suite passing assuming those tests do. This works just like election surveys do - given a small sample, we can predict fairly well that so-and-so percent of the public will vote for candidate A. In our case, the “candidates” are pass or fail, and we can predict how much of the test suite will pass given that sample. Assuming the sample tests all pass, we can say with high likelihood that most of the test suite will in fact pass. (Of course, this is no guarantee, and even a single test failure is serious, however, this gives a quick estimate that your patch does not cause significant and obvious breakage.)

Important Tests

Please see the bottom the file