I don't find any difference between calling t.Errorf and assert.Something with a provided message. Both will populate the test log, with the later giving you more details exactly where things differ from the expectation.
On Monday, October 5, 2020 at 3:03:48 PM UTC+2 Bryan C. Mills wrote: > 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/0b1999e5-d995-4cd5-845f-7fa3eca6efd1n%40googlegroups.com.
