[diegoperini]

I believe TDD is not the only methodology where unit tests are allowed.

As far as I know, TDD suggests that the software is planned and driven by many failing test that are coded initially. A cautious developer may prefer building a feature on top of a failed (later to be satisfied) test but we worry that documenting the target product with all the necessary server and client tests may consume too much time initially. Some features that are likely to be postponed for later releases should not allocate our precious time and in the beginning, we may lack necessary wisdom to foresee it.

The other worry is that TDD in its most basic form is still a coding framework which may leave less freedom for the developer to express his/her preferred productive approach. We prefer to apply a framework on how we communicate, keep track of changes and measure our performance. The rest is left for the developer to experiment and find the most effective style for herself.

[popra]

You don't have to write the unit tests up front for the full app - in fact doing that could be considered going against agility.

The way TDD is usually done is that the developer writes the tests for the feature she's currently working on, before actually working on the feature.