TDD is (among other things) a way to have developers write formal (as in "machine readable") specifications for particular features of a computer program, _ahead of time_. It does this without bothering the developer with intangible (abstract, not-part-of-the-syntax-of-programming-language) late-undergraduate CS concepts like "invariant", "pre-" and "postcondition" etc.
This makes the test not only an affirmation of feature compliance, but a _reasoning tool_ in and of itself. Since tests are specifications written in the target application language and even run in the same runtime, tests can serve the dual purpose of reasoning about the abstract logic of the application as well as the implementation details of the chosen toolchain.
Now, bugs in either tests or toolchain will affect the test results, so while you can kill two birds with one stone, you might break a window in the effort. You now have to make tests for the tests and turtles all the way down.