The way TDD has been described to me makes it sound like TDD is only really useful with unit testing. Does TDD mean all types of testing, such as Acceptance testing, and functional tests?
TDD focuses on very small pieces of code. Classes or methods or (in some cases) very small groups of tightly collaborating objects.
There are test-driven techniques that focuses on a larger scope. Two of these are Acceptance Test Driven Development (ATDD) and Behavior Driven Development (BDD). To my eye, these approaches are similar in intent, though BDD tends to give more emphasis on a particular style of test automation (namely the Given/When/Then style).
What is common between ATDD and BDD is that they start with examples of the whole system's functionality. These examples usually constitute a large subset of the acceptance tests for the system. In contrast, the tests in TDD focus on the functionality of tiny parts of the system.
Mostly I've seen TDD, ATDD, and BDD focusing on functionality.
I myself would not rely solely on automated tests, though there are people who advocate that. I prefer to combine automated tests with exploratory testing.
I have not seen these approaches used for performance testing or security testing, though I suspect some aspects of performance and security testing can be automated. Those are domains where I would want experts to do the testing with their brains fully engaged.
For functional/acceptance testing you need working application, so TDD is much better match for unit testing. But you can plan for functional/acceptance testing, and those test plans may influence your design decisions.