Proposal: show var names in output

[v-braun]

It would be cool to have variable names in the output. Example:

is.Equal(signedin, true) // must be signed in

could be rendered like this:

is_test.go:175: not true: signedin<false> == true // must be signed in

[matryer]

I had this same thought. I quite like it. We should see how well the AST stuff works (see https://github.com/matryer/is/pull/24) as this might make it easy.

[v-braun]

Will check that out in a new experimental branch.

[matryer]

Thanks @v-braun.

While you're there, I wonder how easy it might be to detect where a variable came from, or more specifically where it was last assigned to.

How cool would it be if you would write this:

err := something()
is.NoErr(err)

And get a failure that said:

err: some error  // from: something()

[v-braun]

i have built something simmiliar! will push it later. not exactley your example but is also nice:

is.NoErr(errors.New("BANG!"))

will end in:

err: errors.New("BANG!")

That is for sure not exactley your example but also very helpfull.

I think the other case is also solvable through AST but is much more complex. So in theory I have the error ast.Node and have only to search the entire AST again for a declaration/assignment to this ast.Node.

[v-braun]

see the new PR #25 included are the var names and also your proposal with the variable src (for NoErr)

That is how it looks like:

see is_test.go:170 or this testcase with the error source example.

I am currentley not happy with the print output. There are a lot of information (file, line, var name, var value, var type, comment, err src) in just one line. Maybe there is a better way to format the otput.

Anyhow the AST stuff makes fun and is simpliar than I thout.

[matryer]

@v-braun This is very cool but I'm not sure the complexity is worth it just yet. I'll review the code more. But I had a thought. Maybe it shouldn't show the code if there is a comment? In theory, if you put a comment, that's what you care about isn't it?

[j0holo]

I agree with @matryer, while it is a neat idea this problem can already be solved with a debugger. You know where the test went wrong, put a breakpoint on the function under test and you can inspect each step.

[matryer]

Closing for now, thanks all.