<p dir="auto">My only complaint about <code class="notranslate">deno test</code> is its lack of detail at the time of executing the tests, specially for big codebases.</p>
<p dir="auto">I understand it's influenced by <code class="notranslate">cargo test</code>, but I argue that a much cleaner way to address this is by telling <strong>what file is being tested</strong> 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_.</p>
<p dir="auto">This will improve quite a few aspects:</p>
<h3 dir="auto">Shorter test name</h3>
<p dir="auto">Currently for describing tests that handle different things inside the code you would go with this approach:</p>
<div class="highlight highlight-source-js notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="// 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`, ...);"><pre class="notranslate"><span class="pl-c">// server.js</span>
<span class="pl-v">Deno</span><span class="pl-kos">.</span><span class="pl-en">test</span><span class="pl-kos">(</span><span class="pl-s">`Server starts correctly`</span><span class="pl-kos">,</span> ...<span class="pl-kos">)</span><span class="pl-kos">;</span>
<span class="pl-v">Deno</span><span class="pl-kos">.</span><span class="pl-en">test</span><span class="pl-kos">(</span><span class="pl-s">`Server serves correct files`</span><span class="pl-kos">,</span> ...<span class="pl-kos">)</span><span class="pl-kos">;</span>
<span class="pl-v">Deno</span><span class="pl-kos">.</span><span class="pl-en">test</span><span class="pl-kos">(</span><span class="pl-s">`Server pauses on event`</span><span class="pl-kos">,</span> ...<span class="pl-kos">)</span><span class="pl-kos">;</span>

<span class="pl-c">//With the new approach</span>
<span class="pl-v">Deno</span><span class="pl-kos">.</span><span class="pl-en">test</span><span class="pl-kos">(</span><span class="pl-s">`Starts correctly`</span><span class="pl-kos">,</span> ...<span class="pl-kos">)</span><span class="pl-kos">;</span>
<span class="pl-v">Deno</span><span class="pl-kos">.</span><span class="pl-en">test</span><span class="pl-kos">(</span><span class="pl-s">`Serves correct files`</span><span class="pl-kos">,</span> ...<span class="pl-kos">)</span><span class="pl-kos">;</span>
<span class="pl-v">Deno</span><span class="pl-kos">.</span><span class="pl-en">test</span><span class="pl-kos">(</span><span class="pl-s">`Pauses on event`</span><span class="pl-kos">,</span> ...<span class="pl-kos">)</span><span class="pl-kos">;</span></pre></div>
<h3 dir="auto">Easier to debug assert errors</h3>
<p dir="auto">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)</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="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)"><pre lang="log" class="notranslate"><code class="notranslate">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)
</code></pre></div>
<p dir="auto">The new approach would be more descriptive in less space</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="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)"><pre lang="log" class="notranslate"><code class="notranslate">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)
</code></pre></div>
<h3 dir="auto">Easier to debug compile errors</h3>
<p dir="auto">Currently a failing compile check would output the following</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="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"><pre lang="log" class="notranslate"><code class="notranslate">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
</code></pre></div>
<p dir="auto">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 <code class="notranslate">$deno$test.ts</code> 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.</p>
<p dir="auto">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 <code class="notranslate">--filter</code> would work differently, so maybe a better approach would be an option to switch between this and the classic approach?</p>
<p dir="auto">Would love to hear your thoughts about this, I really feel like this is needed</p>
<p dir="auto">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.</p>
<p dir="auto">In Jest, tests are grouped per file. By default, only file names and names of failed tests are shown.</p>
<h2 dir="auto">Alternative Proposals</h2>
<ol dir="auto">
<li>Show file names alongside test case.</li>
<li>Display a tree of file names and test case. File names are branches, and test cases are leafs.</li>
<li>Create a <code class="notranslate">Deno.testGroup</code> function that acts like <code class="notranslate">describe</code> in Jest, use it in <code class="notranslate">.deno.test.ts</code> to wrap import line of a test file.</li>
<li>Log test file names before execution (similar to <code class="notranslate">cargo test</code>).</li>
</ol>