This past weekend my uncle Keith came up from Virginia. He's a Chiropractor, and while he was here he adjusted me. Afterwards, I realized that what he was doing was very similar to software testing!
The tests that a Chiropractor performs are obviously not automated; he is acting them out as he does them. But we can still take these manual tests and compare them to unit testing. He would say things like "put your arm in this position and then resist me putting pressure on it". Then he would do it an in some cases I would be very weak. Then he would use his adjustment tool, try the test again, and miraculously I would be able to resist his pressure much more easily. He said the science behind what he was doing has to do with your bones crashing into your nerves over time. The tests help expose where this is happening, and the tools / techniques that he uses helps to bring your body back to optimal status in terms of your spine and nerves and whatnot.
See It Fail, Make a Change, See It Pass
When writing unit tests, it's important to see the test failing, then make a change to the source code, and afterwards see the test passing. This helps build confidence that the test is actually checking the functionality that it should be. Interestingly, seeing the test fail (he can easily push down my arm when I resist), then watching him use the tool to press on a certain part of my body, and then seeing the test pass makes me think that there maybe really is something to this treatment after all.
Live Life TDD
It's fine to be addicted to TDD and BDD so much that you start looking through the "test-first" lense for things of than coding; life, friends, movies... Once you enlightened to the tao of automated testing, it will take over your life. But don't fight it. Life is much better that way. ;)