Writing tests as you write the code is just regular and proper software development.
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 :)
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.
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"
https://softwareengineering.stackexchange.com/questions/1236...
Which seems like the exact opposite of what the talk is saying you should do.
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…
