I think that FAQ entry really *is* referring to jUnit-style assert functions, including those provided by testify.
The core of the problem is that `assert` functions generally *cannot* provide enough context to produce useful test failures <http://golang.org/wiki/CodeReviewComments#useful-test-failures>. An `assert` call compares values, but does not report the relevant inputs and calls leading to those values — and the description of the inputs and the operations performed on those inputs are what the person diagnosing the test failure will need in order to figure out what went wrong. If a Go test fails, the person running the test should be able to diagnose the problem from the test log alone, without reading the source code for the test. I just don't see testify-based tests hitting that standard. On Saturday, October 3, 2020 at 1:37:36 PM UTC-4 iko...@gmail.com wrote: > The assert it refers to is the C and other languages assert which makes > the program fail immediately on not satisfying the condition and is used > inline with the rest of the code. In short, the elements that make it bad > Go style are 1. adding the tests together with the running code and 2. > having it crash the program. > > The Go way of doing it is putting it away from the main program, keeping > the main program always safe to run. > > The testify assert copies semantics but not these problems, so there is no > issue at all using it. > > *Joop Kiefte* - Chat @ Spike > <https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=pmam2> [image: > pmam2] > > On October 3, 2020 at 16:05 GMT, jake <jake...@gmail.com> wrote: > > On Saturday, October 3, 2020 at 6:00:10 AM UTC-4 krish...@gmail.com wrote: > >> Hey, >> >> Thanks for both the explanations. They really make sense to me. >> >> I referred to the following link and thought assertions are against go >> best practices => https://golang.org/doc/faq#testing_framework. >> > > I find the link, https://golang.org/doc/faq#testing_framework, to be > confusing as well. I'm not clear on how the hypothetical "assert" it refers > to is different from testing.T.Fatal() > <https://golang.org/pkg/testing/#T.Fatal>. > > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/c96d148e-6b73-40d0-9e3c-b8666b2e9d6dn%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/c96d148e-6b73-40d0-9e3c-b8666b2e9d6dn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/40647eaa-c5f3-4d3c-a2c7-c5dc40012dd8n%40googlegroups.com.
