Suppose you want to instrument some code that touches a database, because you suspect some data (in prod) is coming off the database that is messing your assumptions up, but you don't know yet what specific assumption it is.

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 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?

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.

Yep it’s actually one of the things i love. If waiting for go compile time has gotten to be a problem it is time for tests or to refactor if a test can’t be easily written.

Goes for just about any language tbh.

Does live-reload that runs tests exist?

If you write your tests with Ginkgo [0] its CLI can do this for you.

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.

[0]: https://onsi.github.io/ginkgo/

If it can watch files and trigger your app to boot it can certainly trigfer the test runner.

Yes, on .NET, Visual Studio Enterprise.

https://docs.microsoft.com/en-us/visualstudio/test/live-unit...

this is just a fancy description for a basic rollout system.