21–30 of 46 posts
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
Useful tool, but it has some bugs related to consecutive build failures. Restarting Air is required to fix it. I still use it, just wish I didn't have to restart it frequently.
Wish I heard of air or skaffold. Didn’t find them when searching around this issue.
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.
Does live-reload that runs tests exist?
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.
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.
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?
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.
Does live-reload that runs tests exist?
https://docs.microsoft.com/en-us/visualstudio/test/live-unit...
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.
How would you write the tests to see if the RTL text is being displayed properly on the GUI when switching between LTR and RTL layout mode? 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.
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.
How would you write the tests to see if the RTL text is being displayed properly on the GUI when switching between LTR and RTL layout mode? 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?