4 ms·

I'm not familiar with shaders and game engines, so I'm not sure what you are saying. I had a quick look at godot tests, and seems to me they cover some parts o

by e12e 3mo ago

I'm not familiar with shaders and game engines, so I'm not sure what you are saying. I had a quick look at godot tests, and seems to me they cover some parts of the shaders? Anyway, I was more wondering who/how people are dogmatic about TDD, and manage to leave out one out of three core concepts from red/green/refactor ?

pjmlp 3mo ago
If I cannot write shader code without broken tests, there is a bunch of yak shaving to make testing possible in first place, and that only covers a small subset of graphics pipeline features. It also takes zero consideration for the interactive nature of games/graphics development.
- MoreQARespect 3mo ago
  yes, there is some yak shaving necessary to make writing tests possible. There is often a tension between delivering fast and high quality/bug free and what is necessary for medical software or financial calculations might not be necessary for games. The question of whether to write tests at all is not really about TDD though.
- e12e 3mo ago
  I can't immediately think of what a useful shader test would look like (beyond perhaps, shader doesn't crash program) - if this is something worth discussing, it would probably be useful to see some real world shader code; perhaps especially two versions of the same shader as it evolve. I don't generally test css code to check that a background is now indeed set to "a more mauvey shade of pinky-russet" after a change - but I might want to. I might at least want to run a test with browser automation to check that any text is readable on the background. I could at least find an example of looking at the rendered page for text (as opposed to in the DOM); Google AI had some ideas of how to check the contrast in a screenshot - but no idea if that would actually work as written. https://medium.com/@dzianisv/vibe-engineering-testing-browser-automation-with-ocr-beyond-text-output-validation-717cef1d00d4 https://medium.com/@dzianisv/vibe-engineering-testing-browse... https://share.google/aimode/mW8ClhqGppfpovRrE https://share.google/aimode/mW8ClhqGppfpovRrE

by e12e 3mo ago

pjmlp 3mo ago

If I cannot write shader code without broken tests, there is a bunch of yak shaving to make testing possible in first place, and that only covers a small subset of graphics pipeline features. It also takes zero consideration for the interactive nature of games/graphics development.

MoreQARespect 3mo ago
yes, there is some yak shaving necessary to make writing tests possible. There is often a tension between delivering fast and high quality/bug free and what is necessary for medical software or financial calculations might not be necessary for games. The question of whether to write tests at all is not really about TDD though.
e12e 3mo ago
I can't immediately think of what a useful shader test would look like (beyond perhaps, shader doesn't crash program) - if this is something worth discussing, it would probably be useful to see some real world shader code; perhaps especially two versions of the same shader as it evolve. I don't generally test css code to check that a background is now indeed set to "a more mauvey shade of pinky-russet" after a change - but I might want to. I might at least want to run a test with browser automation to check that any text is readable on the background. I could at least find an example of looking at the rendered page for text (as opposed to in the DOM); Google AI had some ideas of how to check the contrast in a screenshot - but no idea if that would actually work as written. https://medium.com/@dzianisv/vibe-engineering-testing-browser-automation-with-ocr-beyond-text-output-validation-717cef1d00d4 https://medium.com/@dzianisv/vibe-engineering-testing-browse... https://share.google/aimode/mW8ClhqGppfpovRrE https://share.google/aimode/mW8ClhqGppfpovRrE