Just a side note, but essentially the entire field of mind hacking as I teach it is based on TDD. Specifically, the testing of autonomous anticipations: i.e., what your "near" brain expects will happen in a concrete situation, and especially the emotional tags it assigns to that expectation.

If you know how to do that type of testing, you can test any self-help technique designed for changing beliefs, and determine in a matter of minutes whether it's actually any good (assuming you're able to execute the technique correctly, of course).

Most of the techniques I teach people for belief change, therefore, are other people's techniques, but ones whose performance I've been able to verify, via what's effectively TDD. I've also used the approach to refine others' techniques, and develop a few of my own.

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?

Continuing the programming analogy, to fix a bug in a program, you may have to make changes that span multiple code units, and therefore multiple tests. That is, a behavior may be affected by multiple beliefs, at the same or different stages of the behavior. (Fixing a belief that keeps you from even considering public speaking, for example, may not fix a second belief that will cause you to "Bruce" yourself out of the actual speaking engagement.)

However, being able to test at all in a fast feedback cycle is a huge advantage, and I've learned some tricks and heuristics to help find the right "units" ahead of time.