* use subclass of unittest.TestCase for all test cases
* allow to run single test file (eg. python tools/integration_tests.py)
* test filtering (via --pattern/-p CLI flag)
* use common CLI parser for all tests:
usage: test.py [-h] [--failfast] [--verbose] [--executable EXECUTABLE]
[--release] [--pattern PATTERN] [--build-dir BUILD_DIR]
optional arguments:
-h, --help show this help message and exit
--failfast, -f Stop on first failure
--verbose, -v Verbose output
--executable EXECUTABLE
Use external executable of Deno
--release Test against release executable
--pattern PATTERN, -p PATTERN
Run tests that match provided pattern
--build-dir BUILD_DIR
Deno build directory
* respect NO_COLOR variable
Move every test to a method on DenoTestCase.
test.py is a single TestSuite of every TestCase.
Add a Spawn context manager for http_server,
this is explicitly used where it's needed.
Each python test file can now be run independently
without needing to manually run http_server.
Add --help and consistent flags using argparse for
each python test, including --failfast.
Use ColorTextTestRunner so that '... ok' is green.
* Compiler no longer has its own Tokio runtime. Compiler handles one
message and then exits.
* Uses the simpler ts.CompilerHost interface instead of
ts.LanguageServiceHost.
* avoids recompiling the same module by introducing a hacky but simple
`hashset<string>` that stores the module names that have been already
compiled.
* Removes the CompilerConfig op.
* Removes a lot of the mocking stuff in compiler.ts like `this._ts`. It
is not useful as we don't even have tests.
* Turns off checkJs because it causes fmt_test to die with OOM.
This is to ensure a more fair test. Also we were already downloading
from the internet since we changed the URL to use std@v0.5.0. This
change exposes an OOM bug, which is then fixed in the upcoming compiler
refactor by changing checkJs compiler option to false.
op_fetch_module_meta_data is an op that is used by the TypeScript
compiler. TypeScript requires this op to be sync. However the
implementation of the op does things on the event loop (like fetching
HTTP resources).
In certain situations this can lead to deadlocks. The runtime's thread
pool can be filled with ops waiting on the result of
op_fetch_module_meta_data. The runtime has a maximum number of
threads it can use (the number of logical CPUs on the system).
This patch changes tokio_util::block_on to launch a new Tokio runtime
for evaluating the future, thus bipassing the max-thread problem.
This is only an issue in op_fetch_module_meta_data. Other synchronous
ops are truly synchornous, not interacting with the event loop. TODO
comments are added to direct future development.
Some cosmetic fixes to the provided examples in the http README:
- Ensure they're all actually runnable
- Use clear variable names
- Add usage of Cookie interface
Original: b9b25b8b17
