refactor: rewrite deno test, add Deno.test()

[bartlomieju]

• rewrite deno test subcommand - no longer requires to download files from internet
• add cli/testing.ts - this file is a trimmed down copy of std/testing/mod.ts - has only test() and runTests() method
• Rust test js_unit_test now uses Deno.test() to create all test cases instead of relying on std/testing/mod.ts (this is just some dog-fooding)

deno test does not support globs expansion and exclusion. One needs to pass a full list of files that should be run - ie. you can still call deno test */*_test.ts but it is shell's job to expand the glob.
It's really an MVP to take a step back and look at test module to provide essential things to write test. I expect that third party testing frameworks will arise (or be ported from node). So by no means this PR tries to establish a "batteries-included" testing framework.

[nayeemrmn]

Once the std test suite is fully converted to use Deno.test() and std/testing/runner.ts is removed, can we make runTests() internal?

[bartlomieju]

Once the std test suite is fully converted to use Deno.test() and std/testing/runner.ts is removed, can we make runTests() internal?

Still a long way to that... That said, having removed runIfMain leaves only runTests as a way to trigger tests and I see no reason to disallow users to write their own test script that does some fancy stuff.

[nayeemrmn]

write their own test script that does some fancy stuff

Makes sense. If that's the purpose, though, we should make the exposed Deno.runTests() return result data and not do its own logging. That would make the current one unstable if not hidden...

[bartlomieju]

write their own test script that does some fancy stuff

Makes sense. If that's the purpose, though, we should make the exposed Deno.runTests() return result data and not do its own logging. That would make the current one unstable if not hidden...

Sure, but let's discuss after we land this one.

CI still fails on glob expansion on Windows and I don't have a platform to test on 😕 I'm thinking about removing glob functionality completely for now

[nayeemrmn]

Yeah, I never realised how good globrex was. There's nothing that comes close in cargo.

For future: Do we have a way of shelling out small bits of work like this to JS? If not, we should. Then maybe we could bring globrex and the glob expander into cli/js 😆 at least until there is something in rustland.

[ry]

Have you checked that if you insert a failing test into somewhere in cli/js that it will indeed still trigger failure? Same for std?

We need to be careful that we don’t silently ignore test failures when changing the runner.

[ry]

🎉

[bartlomieju]

Have you checked that if you insert a failing test into somewhere in cli/js that it will indeed still trigger failure? Same for std?

We need to be careful that we don’t silently ignore test failures when changing the runner.

Certainly, both cases throw as expected. Keep in mind that this PR does not change testing in std/ - it only affects cli/js/. For std/ PR take a look at #3930

[ry]

LGTM - let's move forward with it - I think we need to get feedback. I'll try to cut a release today with it.

[bartlomieju]

Great, once we land, I'll try to get PR with glob handling working

[ry]

I think as long as it took a directory it would be fine (e.g. deno test .). I don't think that needs glob - you just walk the tree.