Detect and fail on `require.*` methods called from a wrong goroutine about testify HOT 5 OPEN

@ash2k hi

but static analysis likely cannot catch all cases

I think these are very rare cases, because the linter works exactly the same way – it analyzes the call stack.
But it looks as poor workaround for the open source library.

At the moment the Go team is going the static analysis way (go vet's testinggoroutine check), and I'm not sure they'll check the stack rather than just remove the requirement for where these functions should be called.

Because when I was testing my linter, I noticed that many projects (especially the largest ones) use require in goroutines and your proposal will be breaking change for them and looks like candidate for v2 tag.

Anyway sorry for offtop 🙏

from testify.

@Antonboom Don't be sorry: this is totally on topic.

from testify.

No idea how this could be implemented (if ever that is a good idea in the first place).

from testify.

Covered by https://github.com/Antonboom/testifylint#go-require

from testify.

@dolmen Perhaps the check could be implemented by the assertion looking at the goroutine's stacktrace? This might be fragile as stacktrace is not an API so there should be a test for this.

@Antonboom That's cool but static analysis likely cannot catch all cases.

from testify.