You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The stack traces produced by quicktest are extremely awesome.
However, I've found a scenario where they can be verbose in a way that's probably a bug: inline function definitions.
It's probably easiest to just describe this by example:
stack:
/file/system/foo.go:40
qt.Assert(t, err, qt.IsNotNil)
/file/system/bar.go:14
fn(tmpdir)
/file/system/baz.go:16
WithTmpdir("test-foobar-", func(tmpdir string) {
// ... and at this point it proceeds to dump the entire body of the function...
// ... all the way to the ultimate closing paren!
})
Now arguably I'm a monster for having such long inline function declarations that I actually notice this :) But still, I think it would be nice if some kind of elision threshold would exist and be applied by default here.
The text was updated successfully, but these errors were encountered:
warpfork
changed the title
stack trace's report of function signature+args can be unreasonably long for closures
stack trace's report of function+args can be unreasonably long for closures
Jul 12, 2021
This is tricky as it is not easy to figure out when the full definition is actually useful and when it's just noise. In my experience elisions in test outputs are almost never welcomed, but I'd like to read if others have similar issues.
The stack traces produced by quicktest are extremely awesome.
However, I've found a scenario where they can be verbose in a way that's probably a bug: inline function definitions.
It's probably easiest to just describe this by example:
Now arguably I'm a monster for having such long inline function declarations that I actually notice this :) But still, I think it would be nice if some kind of elision threshold would exist and be applied by default here.
The text was updated successfully, but these errors were encountered: