"test" output from deno test seems redundant

[ebebbington]

What Am I Talking About

1. You have a test file
2. You run the tests
3. You see the output, marked bit below is what i'm talking about

test My function returns true when it works ... ok (2ms)
^^^^ this bit

1 tests; 1 passed; 0 failed; ...

What is this issue about
It feels redundant to have the "test" bit display, because we already know it's a test as we're running deno test - and i don't think many other places do this, if any.

[yacinehmito]

i don't think many other places do this, if any.

The output of deno test mirrors the output of cargo test, from Rust. It is the exact same formatting, and it includes the "test" prefix on each line.

[ebebbington]

Still think this is an issue on 1.15, the output still feels ugly imo

running 2 tests from file:///D:/.../a.ts
test getUser() ...
  test returns false ... ok (22ms)
  test returns true ... ok (15ms)
ok (56ms)
test name ...
  test is Edward ... ok (13ms)
ok (30ms)

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (111ms)

The lack of newlines and at ending ok (10ms) are also not pretty imo

[ry]

@ebebbington Can you give an example of how you think it should be formatted?

[ebebbington]

@ebebbington Can you give an example of how you think it should be formatted?

@ry This is how im kinda thinking, in terms of readabillity

Note this is all my own opinion and how I feel, i'm purely trying to think of UX

running 2 tests from file:///D:/.../a.ts
getUser() ...
  returns false ... ok (22ms)
  returns true ... ok (15ms)
name ...
  is Edward ... ok (13ms)
  
running 1 test from file:///D:/.../b.ts
getAdmin()
  returns true ... ok (12ms)

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (133ms)

Note the lack of:

• ok (20ms): Feel this in reality doesn't provide anything on top if the way it's added to the output not feeling pretty. I cant imagine someone finding the execution time of a whole 'suite' useful, where they could just tally up each individual test. I also feel most people would want to check execution time per test case, if a test case has the time, then why the need for the time for suites? You'd usually want to ask yourself "Ok im just going to check is any tests take longer than they should... hmmm the takes 13000ms, whereas all other test cases for the take about 1100ms
• test prefix: i mean it's obvious i guess, we know it's a test - i didn't prefix my test cases with "test" so why is it even there. Adds uncessary characters to the output leading to a more 'bunched' output

And note the addition of:

• newline for every test file after the first one: i really think this improved readabillity, so the output isn't so 'bunched'

[nayeemrmn]

Not having a common prefix can make it difficult to scan

running 2 tests from file:///D:/.../a.ts
getUser() ...
  returns false ... ok (22ms)
  returns true ... ok (15ms)
ok (56ms)
name ...
  is Edward ... ok (13ms)
ok (30ms)

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (111ms)

If not test there should at least be a piece of punctuation. Remember if tests log things or there are errors, other content will be interspersed. So a common prefix at each test name helps a lot in more complex cases.

[ebebbington]

@nayeemrmn what is scanning for "test" and why? (just curious as im unsure)

[MierenManz]

Your eyes would be scanning for the test keyword.

If you have alot of console logging in your tests and alot of tests and you want to check which ones passed. You would have to check the output. Which is hard to differentiate if there isn't the test keyword there.

[ebebbington]

Your eyes would be scanning for the test keyword.

If you have alot of console logging in your tests and alot of tests and you want to check which ones passed. You would have to check the output. Which is hard to differentiate if there isn't the test keyword there.

But the whole output is telling you where test output is and where test output isn't, for example ... ok (2ms)

Imo, i don't really see how the "test" bit can aid in scanning

Regardless of that single point, this whole issue is the reason the Rhum module exists, in my eyes, that says something about some peoples opinions

Would just be good to get a solid discussion around this as to whether it's a "yay" or "nay"

[ebebbington]

Compare this: #7840 (comment)

With this:

running 8 tests from file://.../tests.ts
close()
    Should close the server ... ok (47ms)
    Should not error if server is not set or not defined ... ok (17ms)
    Should not error if server is already closed ... ok (4ms)
on()
    Registers callbacks for the name ... ok (11ms)
    Type checks pass when using generics for channels ... ok (17ms)
to()
    Should send a message to all clienta ... ok (31ms)
    Should send a message to a specific client ... ok (32ms)
run()
    Runs the server ... ok (33ms)

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (286ms)

[bartlomieju]

This was done in v1.21