It's confusing to think of TDD as its own rationality technique: testing your belief that a piece of code works is not fundamentally different from testing any other belief. Okay, so that part is just running unit tests once. Since whether a piece of code works is a different belief from whether that piece of code with a few modifications works, for efficiency, since writing tests is work, you need to keep that tests around and rerun them. So, that's unit testing. TDD is just writing your tests beforehand, which makes a difference in the process of designing software, but not really in how confident you should be that your code works.

Something more interesting to think about is how much information a test gives you that your code works. You can often tell from eyeballing whether switching an integer from positive to negative will make a meaningful difference whether the code produces the intended result.

This really turns into an approximate, poor-man's version of proving code correct, which typically proceeds by breaking down code into its paths and checking each against the mathematical model.

Which reminds me, I have to go prove a few Standard ML functions work by Friday.