Testing in Go: philosophy and tools

Posted May 28, 2020 5:52 UTC (Thu) by jezuch (subscriber, #52988)
Parent article: Testing in Go: philosophy and tools

I guess Go's designers are not very familiar with modern philosophy of unit testing. Nowadays you're supposed to divide each test into three parts, which make it clear that this is the set up of the environment, this is the OUT (object under test), and this is where we make sure that the test results are correct. Frameworks help a lot with this (see e.g. Spock). If you don't do that, like in the mass-of-regular-code examples in the article, I have no idea whatsoever what is actually being tested (I have to infer it from the code, which is always error prone). The least you could do is to add comments marking the three sections (usually called "given", "when" and "then", taking inspiration from - but not really being - Behavior Driven Development).

Testing in Go: philosophy and tools

Posted May 28, 2020 21:26 UTC (Thu) by kunitz (subscriber, #3965) [Link] (2 responses)

The article does contain only one classical Go test, but it uses the typical pattern. A list of test cases is defined that are each tested in a loop. So the functionality tested is at the start of the loop.

I'm always amused when people point out that Go doesn't support concept X. That is actually the strength of the language. The lack of concepts makes it easy to learn, the pedestrian approach feels often dull, but it gets the job done in a way that you will understand in 5 years from now. The strength of Go is the idea of construction of complex things out of little dull things.

Testing in Go: philosophy and tools

Posted May 28, 2020 21:40 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> the lack of concepts makes it easy to learn
It also forces people to use reams of repetitive code and/or search for third-party libraries to do the most basic things. And due to limitations of the language, libraries often can't provide experience that is seamless in other languages.

Go has done a lot of things right, but testing is most definitely not one of them.

Testing in Go: philosophy and tools

Posted Jun 1, 2020 5:30 UTC (Mon) by jezuch (subscriber, #52988) [Link]

> the pedestrian approach feels often dull, but it gets the job done in a way that you will understand in 5 years from now

In the case of tests written as a not-very-structured mass-of-code, I'm pretty sure I won't understand the intent behind the test after 5 days :) The most important thing is not the code itself - it's the intent behind the code. That's something imperative programming is inherently bad at - and the language makes it even worse when it doesn't support concept X.