Definitely. Tests are really like a dual to the code, in the sense that they are another way of describing what it is supposed to do. Like you say, as the test grows more complicated, the risk that the test code itself has bugs grows too.

The risk is small with simple declarative tests ("the output of f(x) == y") but with complicated systems with large state spaces, you start writing combinatorial tests to try to cover more of the space and incur a bigger risk your test code is buggy.

Few things are as frustrating as fixing a bug that should have been caught by a test and realizing the test wasn't actually working correctly. This is even more acute when working on code where speed is important (where performance is correctness, in other words) and you realize a test has been measuring the wrong things, such as asynchronous runtime showing up in the wrong place.

TDD has always seemed more like a useful tactic to be applied to certain kinds of problems than as a silver bullet.