It is not a perfect solution: this type of TDD is definitely just “unit testing” of individual beliefs, whereas a solution to most real-world problems requires that one also does “acceptance testing”—i.e. does your actual behavior change along with the belief, and does it stay changed?
I’m glad to see this distinction made. It’s great to be able to test in almost real time that a technique is having a desirable effect, but some things you just can’t tell until down the track. The obvious example is, as you allude to in a grandchild, whether 2 years down the track you actually have the book written. It’s great if my program is getting all green lights but if it turns out that despite that it just isn’t working then I need to be able to go back, reassess, understand the problem and hopefully create new unit tests that are more rigorous.
I’m glad to see this distinction made. It’s great to be able to test in almost real time that a technique is having a desirable effect, but some things you just can’t tell until down the track. The obvious example is, as you allude to in a grandchild, whether 2 years down the track you actually have the book written. It’s great if my program is getting all green lights but if it turns out that despite that it just isn’t working then I need to be able to go back, reassess, understand the problem and hopefully create new unit tests that are more rigorous.