On: You can't unit test for taste

[e12e]

> TDD dogma of only writing code to fix broken tests.

Isn't red-green-refactor pretty ingrained in TDD?

Only write code to make a failing test pass; then refactor while making sure the tests still pass?

Then write a test that fails, repeat?

[pjmlp → e12e]

Now do a games engine with that approach regarding shaders and the desired visuals.

[e12e → pjmlp]

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 → e12e]

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 → pjmlp]

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.