Respectfully, I think the distinction they're making it that "writing ONE failing test then the code to pass it" is very different than "write a whole test suite, and then write the code to pass it".

The former is more likely to adapt to the learning inherent in the writing of code, which someone above mentioned was easy to lose in TDD :)

Odd, I was taught TDD as

1. Write test, see that it fails the way you expect.

2. Write code that makes the test pass.

3. Write test...

and be secure that you can fearlessly refactor and not backslide while you play with different ideas so long as all your tests stay green.

I would get overwhelmed so fast if I just had 50 failing tests and no implementation.

That's the right way to do TDD, see this talk: https://www.youtube.com/watch?v=EZ05e7EMOLM

One of the above comments mentions BDD as a close cousin to TDD, but that is wrong as TDD is actually BDD as you should only be testing behaviours, which allow you to "fearlessly refactor"

Behavior is an unfortunate term, because the "London Style" TDD sometimes is described as testing behaviors:

https://softwareengineering.stackexchange.com/questions/1236...

Which seems like the exact opposite of what the talk is saying you should do.

I don't think TDD gets to own the concept of having a test for what you're refactoring. That's just good practice & doesn't require that you make it fail first.

Now do that for rendering a rotating cube in Vulkan with pbr shading.

This falls under the category of problems where verifying, hell describing, the result is harder than the code to produce it.

Here’s how I would do it. The challenge is that the result can’t be precisely defined because it’s essentially art. But with TDD the assertions don’t actually have to actually live in code. All we have to do is make incremental verifiable progress that lets us fearlessly make changes.

So I would set up my viewport as a grid where in each square there will eventually live a rendered image or animation. The first one blank, the second one a dot, the third a square, the fourth with color, the fifth a rhombus, the sixth with two disjoint rhombuses …

When you’re satisfied with each box you copy/paste the code into the next one and work on the next test always rendering the previous frames. So you can always reference all the previous working states and just start over if needed.

So the TDD flow becomes

1. Write down what you want the result of the next box to look like.

2. Start with the previous iteration and make changes until it looks like what you wanted.

3. Write down what you want…

Using wetware test oracles is underappreciated. You can't do it in a dumb way, of course, but with a basic grasp of statistics and hypothesis testing you can get very far with sprinkles of manual verification of test results.

(Note: manual verification is not the same as manual execution!)

That isn't what TDD preaches.

TDD also underappreciates the ROI of that.

TDD sales pitch it not to write any code without a test for it, that fails it.

And that’s happening. The next test is “the 8th box should contain a rhombus slowly rotating clockwise” and it’s failing because the box is currently empty. So now you write code.