No silver bullet: Tests help to find bugs, but they can't find bugs that you introduce in the test code and in implementation code. If you haven't understood the problem you need to solve, writing tests most probably doesn't help.

It seems slower at the beginning: If you start TDD, you will get the feeling that you need a longer duration of time for easy implementations. You need to think about the interfaces, write the test code, and run the tests before you can finally start writing the code.

All the members of a team need to do it: As TDD influences the design of code, it is recommended that either all the members of a team use TDD or no one at all. In addition to this, it's sometimes difficult to justify TDD to the management because they often have the feeling that the implementation of new features takes longer if developers write code that won't end up in the product half of the time. It helps if the whole team agrees on the importance of unit tests.

Tests need to be maintained when requirements change: Probably, the strongest argument against TDD is that the tests have to be maintained as the code has to. Whenever requirements change, you need to change the code and tests. But you are working with TDD. This means that you need to change the tests first and then make the tests pass. So, in reality, this disadvantage is the same as before when writing code that apparently takes a long time.