Here it comes, finally, after 9 months of work and a big push in the last few weeks, I am super happy to announce the first beta version of elm-test-rs, a new tests runner for the Elm language. Executables for Linux, MacOS and Windows are available in the assets of the latest release. Special thanks to @harrysarson and @tforgione who have followed along closely and helped me with parts of elm-test-rs!
What is elm-test-rs, why should I care?
Basically, it is an alternative to node-test-runner, which is the library you use when running the
elm-test command. This new tests runner brings some cool new features like capturing and reporting calls to
Debug.log or filtering of tests based on descriptions and should be easier to maintain, extend and update with new elm versions. Here is the project home.
What are the differences with elm-test?
There are many differences, both on the inside, and the outside.
Let’s make a quick list of all major differences.
- elm-test-rs lets you specify the amount of workers used to run the tests.
- elm-test-rs can capture and report calls to
Debug.login failing tests.
- elm-test-rs can filter the tests to run based on their description.
- elm-test-rs lets you choose between an offline mode, or an online mode where it can either pick the newest or oldest compatible versions of dependencies to run the tests, which is convenient for library authors wanting to test dependency lower bounds.
- elm-test-rs is made in Rust mainly, meaning it is fast and a portable executable, it has no npm dependency. It still depends on the elm compiler and Node being installed to run the tests.
- elm-test-rs architecture is simpler and better documented than node-test-runner so it should be easier to maintain, to extend, and to update when a new version of elm is out.
- elm-test-rs is very new and not battle-tested like elm-test, so expect some rough edges. It also only supports the 0.19.1 elm executable, and Node >= 12.
Why did I do this if elm-test already exists?
The origin of this goes back to February of this year (2020), when I was working on the online experience for the Elm track on exercism. In order to let people use the site without having to install anything, there has been a ton of work involving setting up containers and code editors to be able to run user code and report tests failures to the user. At the time, I briefly reported some of the issues I faced in this short post. But one really annoying problem I didn’t manage to solve at the time, was the bad interaction between the presence of
Debug.log in student code, and the reports of elm-test. I made an issue about that in node-test-runner.
Let me know what you think if you try it!
A lot of work and love was put into elm-test-rs, but it is still a beta version, and I’m only able to test Linux locally. So if you are interested in elm-test-rs, give it a try, and let me know if unexpected things happen! To try it, simply download the executable for your system in the latest release assets and run
elm-test-rs in one of your Elm projects.
I leave you here with the output of
elm-test-rs An alternative Elm test runner to node-test-runner USAGE: elm-test-rs [<SUBCOMMAND>] [FLAGS] [TESTFILES] For example: elm-test-rs tests/*.elm FLAGS: --help # Print this message and exit --version # Print version string and exit --watch # Rerun tests on file changes --compiler /path/to/compiler # Precise the compiler to use (defaults to just elm) --seed integer # Run with initial fuzzer seed (defaults to random) --fuzz integer # Precise number of iterations of fuzz tests (defaults to 100) --workers integer # Precise number of worker threads (defaults to number of logic cores) --filter "substring" # Keep only the tests whose descriptions contain the given string --report console|json|junit # Print results to stdout in given the format (defaults to console) --connectivity progressive|offline|online-newest|online-oldest # Connectivity mode (defaults to progessive) # offline: elm-test-rs only use installed packages to solve dependencies # online-newest: the newest compatible dependencies are picked to run tests # online-oldest: the oldest compatible dependencies are picked to run tests # progressive: try offline first and if that fails, switch to online-newest SUBCOMMANDS: init # Initialize tests dependencies and directory install [PACKAGES] # Install packages to "test-dependencies" in your elm.json