Testing in Go: philosophy and tools

Posted May 28, 2020 21:26 UTC (Thu) by kunitz (subscriber, #3965)
In reply to: Testing in Go: philosophy and tools by jezuch
Parent article: Testing in Go: philosophy and tools

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.