Perhaps the new -fullpath flag added for #37708 covers your use case?
You've shown a passing test, but that's usually uninteresting.
With a failing test it would print

--- FAIL: TestXXX (0.00s)
    example.com/testrepo0295/main_test.go:6: it broke
FAIL
exit status 1
FAIL	example.com/testrepo0295	0.001s

I don't think we can change the default output, but we could add a new flag like -test.fullpath if that is not enough.

@seankhliao I think that would indeed solve the problem in most cases, but only if you think to use -fullpath in the first place. If the current verbose test output format won't be changed, then I suppose remembering to use -fullpath is no worse than remembering to use a new -printpkg flag for the proposed behavior.

One case where it wouldn't work is if t.FailNow() is used without other output, which is probably rare, but still possible:

=== RUN   TestCreate
--- FAIL: TestCreate (0.00s)
=== RUN   TestDelete
--- FAIL: TestDelete (0.00s)

I didn't understand from #37708 the reason why changing the output format would break anyone. I could understand that position for changing the JSON format, but what would break if, say, a === RUN pkg/path line was added?

I do like the symmetry of before/after package delimiters for package results, like we have for tests, but perhaps that's just me.

I just ran across a different case where this would be useful, and -fullpath doesn't help.

If a test hangs forever, you can get output like this (all tests are parallel):

[...snip...]
=== NAME  TestIntegrateRealQueueDeleteMessage
    integration_test.go:58: 2a
--- PASS: TestIntegrateRealQueueSendMessage (0.50s)
=== CONT  TestRetryQueueDeleteMessage
--- PASS: TestIntegrateRealServiceUserActive (1.46s)
=== CONT  TestRetryQueueReceiveMessage
--- PASS: TestRetryQueueDeleteMessage (0.05s)
=== CONT  TestRetry
--- PASS: TestRetry (0.00s)
--- PASS: TestRetryQueueReceiveMessage (0.05s)

There's no clear indication of what test is hanging. Nothing is logged, so -fullpath doesn't help.