To answer your question, I would say, what you state is right, partly.

TDD makes extensive use of unit tests, but also acceptance test. If you look at the full TDD test cycle described in Growing Object-Oriented Software, Guided by Tests, it is:

1. Write a failing acceptance test
2. Write a failing unit test
3. Make the failing test pass
4. Refactor
5. Repeat steps 2-4 until the failing acceptance test passes

By definition acceptance tests are end-to-end tests that start from the user input level through all your application stack (including domain objects, external services and databases).

Because of this you will not only test your components and define interaction there, but also base them on overarching acceptance tests that proof your components work together.

This will provide you with enough certainty so you are able to impose structural and architectural improvements on your code whenever required.

If you want to see this in action check this TDD session with Uncle Bob.

To answer your question, I would say, what you state is right, partly.

TDD makes extensive use of unit tests, but also acceptance test. If you look at the full TDD test cycle described in Growing Object-Oriented Software, Guided by Tests, it is:

1. Write a failing acceptance test
2. Write a failing unit test
3. Make the failing test pass
4. Refactor
5. Repeat steps 2-4 until the failing acceptance test passes

By definition acceptance tests are end-to-end tests that start from the user input level through all your application stack (including domain objects, external services and databases).

Because of this you will not only test your components and define interaction there, but also base them on overarching acceptance tests that proof your components work together.

This will provide you with enough certainty so you are able to impose structural and architectural improvements on your code whenever required.

If you want to see this in action check this TDD session with Uncle Bob.