Issue 1:
My only complaint about deno test is its lack of detail at the time of executing the tests, specially for big codebases.

I understand it's influenced by cargo test, but I argue that a much cleaner way to address this is by telling what file is being tested at the time of running the test. Specially since Deno does pattern match when running it's tests instead of looking for them inside the code itself _ a la rust_.

This will improve quite a few aspects:

Shorter test name

Currently for describing tests that handle different things inside the code you would go with this approach:

// server.js
Deno.test(`Server starts correctly`, ...);
Deno.test(`Server serves correct files`, ...);
Deno.test(`Server pauses on event`, ...);

//With the new approach
Deno.test(`Starts correctly`, ...);
Deno.test(`Serves correct files`, ...);
Deno.test(`Pauses on event`, ...);

Easier to debug assert errors

The stack trace does it's job, but it's just harder to guess where it's failing following this approach (specially when it fails on multiple tests)

at assertEquals (file:///home/nicolas/Documents/Programming/deno/std/testing/asserts.ts:196:9)
at file:///home/nicolas/Documents/Programming/deno/std/node/_stream/stream_test.ts:40:3
at async asyncOpSanitizer (deno:cli/rt/40_testing.js:34:7)
at async Object.resourceSanitizer [as fn] (deno:cli/rt/40_testing.js:68:7)
at async TestRunner.[Symbol.asyncIterator] (deno:cli/rt/40_testing.js:240:13)
at async Object.runTests (deno:cli/rt/40_testing.js:317:22)

The new approach would be more descriptive in less space

running 34 tests
-- stream_test.ts
test Stream to async iterator ... FAILED (5ms)
test Stream to async iterator throws on 'error' emitted ... ok (7ms)
-- async_iterator_test.ts
test Async iterator matches values of Readable ... ok (1ms)
test Async iterator throws on Readable destroyed sync ... ok (7ms)
test Async iterator throws on Readable destroyed async ... ok (5ms)
test Async iterator finishes the iterator when Readable destroyed ... ok (5ms)

Easier to debug compile errors

Currently a failing compile check would output the following

deno test
Check file:///some_folder/$deno$test.ts
error: TS2790 [ERROR]: The operand of a 'delete' operator must be optional.
delete progress.queued;
~~~~~~~~~~~~~~~
at https://deno.land/std@0.66.0/testing/bench.ts:323:10

I guess this is because the files are being checked all together after being matched by the test file pattern, so the main file would be resolved to $deno$test.ts but it makes it really hard to debug which one of the files has a compile error when the error isn't in the file itself. This would be solved as well by executing each file separately.

I'm not sure if this would be a breaking change, I'm sure it would involve tons of work though, and the tools like --filter would work differently, so maybe a better approach would be an option to switch between this and the classic approach?

Would love to hear your thoughts about this, I really feel like this is needed

Issue 2:
Currently, all tests from different test file are printed as if they are all from one file. This could be a problem on a large test suite where developer needs to find failed test case/file.

In Jest, tests are grouped per file. By default, only file names and names of failed tests are shown.

Alternative Proposals

Show file names alongside test case.

Display a tree of file names and test case. File names are branches, and test cases are leafs.

Create a Deno.testGroup function that acts like describe in Jest, use it in .deno.test.ts to wrap import line of a test file.

Log test file names before execution (similar to cargo test).