Given go's nature of being more network oriented, I think these questions are a bit disingenuous.

Go comes with a lot of facilities for testing the things it's good at.

If testing GLSL shaders, or gui applications is difficult, I'd consider putting at least some pressure on the tooling providers to provide better testing facilities.

I'm more familiar with how opengl & shaders work than I am with text rendering - so I'll keep my commentary towards the shader question. At least on the surface it seems de-composable into two distinct problems: Is the shader emitting the correct colors after gamma correction is applied, and is that rendering appearing on the screen.

The former could be tested by rendering to a buffer and capturing the output, and asserting against an expected color value.

The latter is where I'd say that better tooling is indeed required.

Ah the typical answer when TDD advocates get challenged at conferences regarding UI testing.

Advocacy works great when only data structures get tested.

I lnow you're saying that when it comes to GUIs you have to do it manually, but as someone working on the back-end this begs the question: is there no unit tests framework or anything for GUIs ?

Depends if we are talking about native or web based GUIs, and then the best you can get is automating the user clicking buttons and if the UI changes in some limited ways.

There is no way to properly test UI/UX experiences, even if the test is correct for a button being displayed with the right label, doesn't mean it looks correctly from user experience point of view, yet the test is green.

Taking repeated screenshots of a GUI and making sure they don't change across commits is a useful thing to have in CI a lot of the time to make sure if you did change something somebody's eyeballed it for correctness.

However I'm not at all claiming that removes the 'eyeballed it' step, just that it makes it harder to miss said step :)

I'm expecting someone to train a ML model soon to interpret and score GUIs.

"This page is confusing" and "This page no clear call to action" And "This page is ugly" And "This button doesn't look like a button."

For native Android apps there is a framework to do GUI tests. The test code stayed in your release as a NOOP last time i looked at it, may be fixed now.

There are, but nothing really satisfactory to be honest. GUI testing is still an unsolved problem in my book.

Write a test that launches the application and checks relevant pixels, at the very worst. Which is not generally all that hard. Bonus points if you save the full image so you can see expected / actual results easily.