I have thoughts about the impact of assertion libraries in software engineering. I came from a background where they are commonplace into Go and in my earlier projects I used some the earlier iterations on them (go-check).
While it's true that developers *can* use assertion libraries to provide rich information about failures, in the vast majority of cases they don't and this gets past review because without enrichment there is just enough information to not be completely useless; you end up with something along the lines of `assert.Equal(got, want)` which will emit the line and a diff, but not any additional context, nor an contextually relevant diff, while with a plain pkg/testing-based tests, the author *must* include explicit context tailored for the setting to get past any reasonable code review. The outcome then is weaker information in the failing case and often more of it, so the work needed to debug failures is compounded. The other impact of assertion libraries is that they have gone to the effort to compose a multitude of different tests from the small number of language primitives that actually do the work of assessing a test's success or failure which means that instead of needing to know just the language, which I already do because I am writing code in it that is being tested, I also need to know the assertion library's idioms and quirks — often requiring digging several abstraction layers into the assertion library — so there is a not insignificant additional cognitive burden at the very time when cognitive burdens need to be minimised (while debugging an issue). Having seen both sides of approaches to testing, I am very glad that Go does not promote the use of assertion libraries and I am sad that so many people who write Go code have adopted them despite the project's recommendation not to. On Wed, 2022-01-12 at 14:56 -0800, Romenigue Thier wrote: > Hello! > > Recently I learn the page TestComments on Golang Wiki (on Github). > The section about Assert Libraries discourage the use of them. > But I guess there's a little bit mistake in this approach because we > have good libraries that provide assert functions. > The argument omits interesting information about what the test got > right is not the real true, is more easy to understand what the test > does with 2 or 3 asserts than a if with 2 or 3 ORs inline. > Furthermore libraries as Testify provide rich and easy-readable > informations when the test fails in the assert functions. > Finally, using asserts or ifs don't guarantee that the test is right, > the argument Assert libraries make it too easy to write imprecise > tests is more about the quality of test than the use of an assert > library. > > Any thoughts? -- 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/215a544be4848e361ad3fb511ca8c6a8a7265a14.camel%40kortschak.io.
