Closed Redfire75369 closed 2 weeks ago
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.
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.
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.
cargo-nextest
works as I expected. Process Isolation means each test can have its own runtime.
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.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 thefs
module can then be tested independently, and properly utilise cargo's test system, with many tests and test cases.Requirements
Possible Solution
thread_local
orMutex
could be used to store theParentRuntime
andRuntime::create_with_parent
could be used to create the appropriate runtimes.