Testing in Go: philosophy and tools

Posted May 27, 2020 17:11 UTC (Wed) by cpitrat (subscriber, #116459)
Parent article: Testing in Go: philosophy and tools

By not having a "domain specific language" for testing (this is what we call functions and these are part of the language too, provided by a library) it means that go tests are full of copy-pasted code with repetition.

Among go tests, I've seen multiple times ettor messages that were invalid because copied from the previous function (e.g saying no error when it checked that there was an error). Or inconsistent order for messages saying what it got vs. what it wants, or worse printing got <want>, want <got>.

Duplication sucks because of that. Go community thinks that WET (write everything twice) is better than DRY (don't repeat yourself) ignoring years of computer science experience and wisdom. Proof-reading tests in a large Go code base is a good way to understand why they're wrong.

Testing in Go: philosophy and tools

Posted May 28, 2020 20:45 UTC (Thu) by kunitz (subscriber, #3965) [Link] (1 responses)

The relevant Go Proverb is: "A little copying is better than a little dependency." But it doesn't mean that people should copy bugs.

Testing in Go: philosophy and tools

Posted May 29, 2020 14:36 UTC (Fri) by cpitrat (subscriber, #116459) [Link]

The reality is that these are excuses to argue that not having generics is not a big deal. Writing a clean assert_equal method (and friends) is hard because of lack of generics. But rather than admit it and say it's a nice thing we can't have yet, the Go community developed some kind of Stockholm syndrome and says that they don't want it anyway for weird reasons, including that repeating yourself is great.