Multiple Tests in One File

[Redfire75369]

Issue

Currently, there is a limitation to the usage of tests as only 1 test per file can be created to test actions within the runtime. This is due to the following. Hence, only 1 runtime can be initialised per thread. Due to how cargo tests are run serially(with --test-threads=1) and in parallel, this means only 1 runtime can be initialised per executable, which requires 1 file per test.

It is currently not possible to initialize SpiderMonkey multiple times (that is, calling JS_Init/JSAPI methods/JS_ShutDown in that order, then doing so again). This restriction may eventually be lifted.

Finding a solution to this will improve flexibility for future tests with more complex modules, and JSAPI wrappers.
Currently, I have a draft of tests for the fs module, but I am not satisfied with them, as putting them all in a singular function partially defeats the purpose of such tests, as they are not targeted. With this improvement, each portion of the fs module can then be tested independently, and properly utilise cargo's test system, with many tests and test cases.

Requirements

• Advanced Understanding of Rust, static values and cargo tests
• Intermediate Understanding of JavaScript
• Understanding of Spidermonkey Runtime and Engine initialisation

Possible Solution

thread_local or Mutex could be used to store the ParentRuntime and Runtime::create_with_parent could be used to create the appropriate runtimes.

[Redfire75369]

cargo-nextest could also be a possible solution. It seems to spawn each test in a separate process. I'll try it later, after completing the http module.

[wesgarland]

Have you tried to dlopen / dlclose libmozjs between tests? There isn't a lot of storage that doesn't live in the ctx, IIRC the rest of it is in TLS which should get unmapped when you dlclose the solib.

Another alternative might be to eschew the init/teardown for each test, instead tying that to the process. In each test you could, instead, initialize a new global object and set of standard classes. That would give you test-isolation similar to web workers in the browser.

[Redfire75369]

dlopen/dlclose wouldn't really work. Currently mozjs is statically linked and changing that to be dynamically linked would be an extreme pain.

Creating a new global should be possible, and is definitely something I'll be trying later. First I need to figure out how to store the engine handle and context in a thread local so they can be accessed.