This shouldn't need to be the case with TDD. TDD is a tool for evolving the design & functionality. The whole reason for using it is that you don't know what you want beforehand.
With TDD you write a failing test, write the smallest amount of code necessary to make it pass, then refactor. After that you add another test and go round again. You can use this to drive your design for low level unit/model tests.
When writing higher level acceptance tests I like to write the tests in using the language you share with the customer [1]. If you do this then they should remain valid unless the requirements change, they should not be dependent on your understanding of the requirement. To achieve this you can have your tests manipulate a domain model. If you are not testing your model then you need a model for your tests. e.g. something like the page object pattern for webdriver[0].
This means you can sketch out your high level tests rapidly with a stub model, and then implement the mapping to your implementation once you have got the implementation more stable.
Adding a layer of indirection to the implementation like this also means you can refactor your implementation as much as you like without touching the test itself. You may need to modify the mapping between the language your tests use and the implementation as you change the implementation. This sort of test can be valid across major re-writes of the implementation. The tests should also be less brittle. If you change something that several tests interact with you should only need to update one place to fix it.
For integration tests I like to use the same approach, except now the language used relates to the common concepts across the two systems you are testing integration of. The concepts used in the APIs.
Comments
This shouldn't need to be the case with TDD. TDD is a tool for evolving the design & functionality. The whole reason for using it is that you don't know what you want beforehand.
With TDD you write a failing test, write the smallest amount of code necessary to make it pass, then refactor. After that you add another test and go round again. You can use this to drive your design for low level unit/model tests.
When writing higher level acceptance tests I like to write the tests in using the language you share with the customer [1]. If you do this then they should remain valid unless the requirements change, they should not be dependent on your understanding of the requirement. To achieve this you can have your tests manipulate a domain model. If you are not testing your model then you need a model for your tests. e.g. something like the page object pattern for webdriver[0].
This means you can sketch out your high level tests rapidly with a stub model, and then implement the mapping to your implementation once you have got the implementation more stable.
Adding a layer of indirection to the implementation like this also means you can refactor your implementation as much as you like without touching the test itself. You may need to modify the mapping between the language your tests use and the implementation as you change the implementation. This sort of test can be valid across major re-writes of the implementation. The tests should also be less brittle. If you change something that several tests interact with you should only need to update one place to fix it.
For integration tests I like to use the same approach, except now the language used relates to the common concepts across the two systems you are testing integration of. The concepts used in the APIs.
[0] http://code.google.com/p/selenium/wiki/PageObjects [1] Ubiquitous Language http://martinfowler.com/bliki/UbiquitousLanguage.html