When writing go, I've always found if I find myself constantly restarting & recompiling a program during development, it means that I should be writing tests instead.
Because it's just a gut feeling, you can't write a test against it
How would you write the tests to see if the GLSL shader is displaying the mesh on the screen with the correct gamma correction factor?
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.
Advocacy works great when only data structures get tested.
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.
"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."
However I'm not at all claiming that removes the 'eyeballed it' step, just that it makes it harder to miss said step :)
It also has nice facilities to quickly disable a test or portion of a test by prepending an X to the test function name, or to focus a test (only run that test) by prepending an F. It’s pretty nice.
https://docs.microsoft.com/en-us/visualstudio/test/live-unit...