Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stack trace's report of function+args can be unreasonably long for closures #104

Open
warpfork opened this issue Jul 12, 2021 · 1 comment

Comments

@warpfork
Copy link

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.

@warpfork 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
@frankban
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants