It's not comprehensive documentation, it's a process of software development. Start with the most simple test first, make it green via the most simple implementation, refactor. (Red/Green/Refactor). Repeat until you can not adjust your tests/specs and implementation anymore.

Doing TDD you'll not create comprehensive documentation upfront but will switch your testing- and implementation-hat every few minutes.

Not at first, but by the time your software is working, you will have comprehensive documentation about it.

> Doing TDD you'll not create comprehensive documentation upfront

Where did the idea of 'upfront' come from? Having comprehensive documentation before you have working software doesn't mean having comprehensive documentation before you have any software.

Tests serve a different purpose. They are not for humans to read, they are to make sure your software works ("working software"). They are an important component of Agile because it makes it easier to change your code without breaking things.

Now, I am not big into TDD, but for me, it is an approach that is fully compatible with the Agile manifesto.

Test is the action that is carried out from the documentation, possibly by a human, but more likely by a machine. We are talking about the document that describes what the program is intended to do, which is then followed to carry out the tests.

> They are not for humans to read

I should hope your documentation is there for humans to read. If not, even small modifications required as business needs change would become a complete nightmare. The tests you need to perform, and thereby the documentation that needs to be followed, will not remain static through the entire lifetime of the application.