[numpy-thagoras]

You write the requirements, you write the spec, etc. before you write the code.

You then determine what are the inputs / outputs that you're taking for each function / method / class / etc.

You also determine what these functions / methods / classes / etc. compute within their blocks.

Now you have that on paper and have it planned out, so you write tests first for valid / invalid values, edge cases, etc.

There are workflows that work for this, but nowadays I automate a lot of test creation. It's a lot easier to hack a few iterations first, play with it, then when I have my desired behaviour I write some tests. Gradually you just write tests first, you may even keep a repo somewhere for tests you might use again for common patterns.

[pjmlp]

I want to have a CUDA based shader that decays the colours of a deformable mesh, based on texture data fetched via Perlin noise, it also has to have a wow look as per designer requirements.

Quite curious about the TDD approach to that, espcially taking into account the religious "no code without broken tests" mantra.

[CuriouslyC]

Break it down into its independent steps, you're not trying to write an integration test out of the gate. Color decay code, perlin noise, etc. Get all the sub-parts of the problem mapped out and tested.

Once you've got unit tests and built what you think you need, write integration/e2e tests and try to get those green as well. As you integrate you'll probably also run into more bugs, make sure you add regression tests for those and fix them as you're working.

[pjmlp]

Got to figure that TDD for the UX wow designer part.

[sarchertech]

TDD is terrible for anything where the hard part is the subjective look and feel.

[MoreQARespect]

1. Write test that generates an artefact (e.g. picture) where you can check look and feel (red).

2. Write code that makes it look right, running the test and checking that picture periodically. When it looks right, lock in the artefact which should now be checked against the actual picture (green, if it matches).

3. Refactor.

The only criticism ive heard of this is that it doesnt fit some people's conceptions of what they think TDD "ought to be" (i.e. some bullshit with a low level unit test).

[CuriouslyC]

You can even do this with LLM as a judge as well. Feed screenshots into a LLM as a judge panel and get them to rank the design 1-10. Give the LLM judge panel a few different perspectives/models to get a good distribution of ranks, and establish a rank floor for test passing.

[sarchertech]

That only works for the simplest minimally interactive examples.

It is also so monumentally brittle that if you do this for interactive software, you will drive yours nuts trying.