I see your point that there are some thing that seem awkward for testing. It’s a good and interesting one that really should be considered. Game software is replete with examples like these.
But just to attempt… to TDD a graphics shader one would have to consider the side effects of the shader to be able to craft a test for it.
And then to reverse once again, given a graphics shader is typically up to the vis artist and that artist would need to muck around to find what looks good, it almost doesn’t make sense to write a test at the beginning.
For me, I don’t typically write non-disposable write tests on my shaders. I just make the simple shaders. If it’s a tricky shader, or I want to capture a funky edge case, I’ll write a disposable test so I can try to iterate faster on the shader. Running a test that takes 1-2 seconds to see results for each iteration of code is faster (for me) than waiting 20-30 seconds for Unity to load my test scene. I still have to visually check it at the end of the process but I find for my workflow it helps me go faster.
I wouldn’t dare say “it’s good for me, therefore everyone needs to do it.” I’m just sharing my experience.
Remmeber, don't write production code without a failing test first.