What do you think is lacking from deno test output?

[caspervonb]

The output format for deno test has more or less just been taken from libtest, which works great for Rust since it has fully qualified names but feels like it is time we allow ourselves to diverge from that.

So open ended question here as I'll be poking at all things that is the test runner, what do you feel is lacking in the output format?

Additional prior art examples from various frameworks and other runners like go test would be appreciated as-well.

[grian32]

When doing assertEquals on an array or something aloing those lines, the diff's are pretty hard to read, its mostly the way itts displayed, especially the fact that it doesn't have any line numbers, this could be fixed by adding line numbers, or putting them side by side and so on so forth. Not sure on examples to give of how other testing frameworks do this.

[ebebbington]

Grouping test output ;) Grouping it makes it so much easier to read (for me atleast), to understand the where and what. For example with Deno.test, my test names look like "tests/unit/server/something_test.ts | Server | constructor() | Correctly sets the config property when param is passed in"

[caspervonb]

Yeah preferably we'd indent this properly, something like:

Running tests from file://foo/bar/baz.ts
  ok      test1
  FAILED  test2

[ebebbington]

i like it :)

[ebebbington]

Maybe don't cut off assertion output if it's too long? There's been times where a test fails, but the actual output looks like - "I am some string, i am the expected response, i am a very long string blah blah bl...", meaning i have to do some extra debugging to log what that data is, as opposed to seeing it in full in the output

[caspervonb]

Agreed

[Skillz4Killz]

• console.log is a bit weird
• If ms is a high number, would be nicer to have a cleaner, human-readable format
• Possibly replace ok with a pass or PASS or ✅ The ok always felt a bit weird to me

[Mee42]

I worked with a program once that printed JOLLY GOOD on success, which in my opinion would look nicer than ok. Given that FAILED is all capitalized, maybe OK would look a lot better?

[grian32]

@Mee42 10/10 JOLLY GOOD suggestion lad, happy to have you here giving such great ideas.

[cdoremus]

I'd like to see the console indicator of passing test (PASS) in green while the failure marker (FAIL) would be red following the red/green/refactor pattern.

[MierenManz]

such a small inconvinience, but a new line after each test would be nice
so that you don't en up with stuff like test ree ... Im console.log

That's the only thing for me.

[caspervonb]

Yeah I want to just always capture stout and print it with failures, since the reporter is no longer going to be tied to stdout directly but goes via an internal messaging channel this is much more doable.

[cknight]

Minor suggestion. Include the number of test files run in the summary. E.g.

test result: ok. 191 passed (from 31 files); 0 failed; 0 ignored; 0 measured; 0 filtered out (545ms)

[caspervonb]

sgtm, will keep it in mind.

[nachocab]

@caspervonb It would be great to have more meaningful diffs when comparing objects.

Seeing "expected [ Array(3) ] to deeply equal [ Array(3) ]" is not very useful. 😅