3 ms·

What you said has absolutely nothing to do with TDD. What you described is just automated test, which is a good thing. TDD means you write a failing test case

What you said has absolutely nothing to do with TDD. What you described is just automated test, which is a good thing. TDD means you write a failing test case first before you write the actual function. You don't need TDD to "run a unit test to test a function in a fraction of a second". TDD is only good when the spec is unambiguously defined (either in your mind, or written by a product designer). For example if you need a function that tests whether two AABBs are overlapped, TDD is perfect. But in game development, sometimes the spec is just "write a water shader that looks good enough", and "good enough" is not unambiguously defined. Therefore TDD is bad in this case.

MoreQARespect 4y ago
Sounds like snapshot test driven development would work well in that case though: https://hitchdev.com/hitchstory/approach/snapshot-test-driven-development/ https://hitchdev.com/hitchstory/approach/snapshot-test-drive... Write a scenario that uses a new water shader - eyeball it - if it's good then "fix" the snapshot and pass it around. Repeat with a few other scenarios to see it performing under all relevant circumstances. It can be a bit tricky if the result of the shader is not deterministic - but there are sensible ways of dealing with that.