Another very useful aspect of TDD (and well-structured tests in general) is documentation. In most cases, it is much easier to find out what the code does by looking at tests than at the implementation itself. What is the purpose of some methods? Look at the tests associated with it. What is the desired functionality of some part of the application UI? Look at the tests associated with it. Documentation written in the form of tests is one of the pillars of TDD and deserves further explanation.
The main problem with (traditional) software documentation is that it is not up-to-date most of the time. As soon as some part of the code changes, the documentation stops reflecting the actual situation. This statement applies ...
