Improve debuging

[bkielbasa]

Describe the bug When tests fail, in the console we can find error logs which don't point the line where the actual problem is but where the panic (in most cases) was caught.

To Reproduce

All you need to do is to change something in a test to fail it.

[bkielbasa]

do you have any idea how to fix it? We cannot go with a stable version with an issue like that :)

[sagikazarmark]

Well, for one I'm not sure every step must actually be a subtest.

[bkielbasa]

I did that to improve readability while watching the output of the test execution.

[arberiii]

@bkielbasa to catch when the actual error happens we may have to use the runtime package. Here is how we can implement it

type Err struct {
    err  string
    line int
    file string
}

func NewErr(s string) Err {
    stack := make([]uintptr, 1) // here only the first call will be caught
    _ = runtime.Callers(2, stack[:])
    file, line := runtime.FuncForPC(stack[0]).FileLine(stack[0] - 1)
    return Err{err: errors.New(s), file: file, line: line}
}

func (e Err) Error() string {
    return e.err
}
...

    return ctx, NewErr("the math does not work for you")

Then err values will be err.file = gobdd_test.go, err.line=136 Then whenever we read error, we can also get in which file and which line it was called. What do you think?

[bkielbasa]

I think that the problem is more complicated. We can use the code you provided but it will work only for built-in errors (created in the library) but the end-user doesn't have to use them. In such a case, we won't have the trace. We can force the user to use "our" errors but iMO it's not a good idea.

Another scenario - panics. We can use the runtime to get the stack trace.

[bkielbasa]

Here's my proposal for the fix: https://github.com/go-bdd/gobdd/issues/73 Any other ideas?

[bkielbasa]

PRs are merged so I'm closing it :)