Two test suites, two targets
This project has two separate test suites and they run on different targets with different commands. The first is 86 unit tests inside the engine source, which compile for the host machine and run under cargo test in a fraction of a second. The second is 11 tests in a separate file that compile only for WebAssembly and run under wasm-pack test. The split is not arbitrary: the two suites cover things that genuinely cannot be checked in the same place, and running only the first gives a misleading sense of coverage.
The 86 native tests
The unit tests live in the same file as the engine and exercise the pure Rust API: the arithmetic, the memory register, the calculation history, and the error cases. They cover the edge conditions that motivated writing the engine in Rust in the first place, including division by zero, the square root of a negative number, factorial overflow at 21 and beyond, floating point imprecision when adding a tenth to a fifth, and values as extreme as ten to the power of 150.
These run natively because the crate is built as both a system library and a WebAssembly module. That is what the two crate types in the manifest are for. Running them needs no browser, no headless driver and no WebAssembly toolchain, so they are fast enough to run on every save.
The 11 WebAssembly tests
The second file is gated at the top by an attribute that compiles it only when the target architecture is wasm32. On any other target the file compiles to nothing. That is deliberate, and it has a consequence worth knowing: running cargo test reports the file as containing zero tests. They have not been skipped and they have not failed. They simply do not exist for the host target.
They exist because three things are invisible to a native test run.
- The exported wrappers. The methods JavaScript calls are renamed at the boundary, so what a native test calls and what a browser calls are different functions.
- The error conversion. Turning a Rust error into a JavaScript exception has two implementations, one real and one a stub that exists so the crate compiles natively. Only the WebAssembly build exercises the real one.
- The history serialisation, which turns a Rust vector into a JavaScript object and cannot run without a JavaScript environment to build the object in.
Together those are the whole reason the second suite exists. A native test that passes tells you the arithmetic is right; it tells you nothing about whether the thing a browser actually calls is wired up correctly.
Running each suite
cargo test— the 86 native unit tests.wasm-pack test --node— the 11 WebAssembly tests, named in the comment at the top of the test file../guard.sh— the offline gate, which runs the native tests plus the content and schema guards described below.
There is a third body of tests beyond the two Rust suites. The static pages on this site are generated by a small Go program in the repository, and that program and its guard have their own test suite, run with go test. Those tests check that every page carries a title, description, canonical URL and structured data, that the sitemap agrees with the pages that actually exist, and that the calculator's own markup has not lost the hooks its JavaScript binds to. The build page lists the commands in order.
Questions and answers
How many tests does this project have?
86 native Rust unit tests and 11 tests that run against the compiled WebAssembly, plus a separate Go test suite for the static page generator and its content guard.
Why does cargo test report zero tests for the WebAssembly file?
Because the file is gated to compile only for the wasm32 target. On a native run it compiles to nothing, so there is no test to report. Run it with wasm-pack test --node instead.
Why are separate WebAssembly tests needed at all?
Three things are invisible to a native run: the renamed exported wrappers a browser actually calls, the real conversion of a Rust error into a JavaScript exception, and the serialisation of the calculation history into a JavaScript object.
Can the engine be tested without a browser?
Yes. The crate builds as a native library as well as a WebAssembly module, so the 86 unit tests run directly on the host with no browser and no headless driver. The 11 WebAssembly tests run under Node rather than a browser.