Yes and no, I think.

First a caveat: I have worked in a variety of development environments,  
none of which use "TDD" per se, but at least some of which did rely on  
automated tests as a specific tool for ensuring code correctness.  So I  
can't really speak from the TDD perspective per se, but I at least know a  
little about the idea and have a reasonably broad range of experiences  
with varying approaches to testing.  :)

Anyway, I don't think your observation is wrong.  It's just that you seem  
to be implying that this sort of requirement for revision is a bad thing.

I think that whether you write the test first or later, there is always  
still the potential for it to need rewriting.  So it's not like you can  
ensure that you only ever have to write a test once.

One thing I like about the idea of writing the tests first is that they  
become part of the specification that documents how the actual code is  
supposed to work.  I've had too many experiences with vague  
specifications, or specifications that are demonstrably incorrect, often  
in the sense that they describe behavior that's impractical or  
impossible.  Developing a test case can often reveal these flaws before  
you get too far into the code design

The other thing is that you seem to be saying that a redesign of your code  
will always require a rewrite of the test.  This is only true if you take  
the test paradigm to its extreme limit (which is certainly possible, but  
not necessarily common).  If the automated tests focus only on the outer  
layers of the code, on those things described by an operational  
specification, then the only thing that should really require a test  
rewrite is if that specification itself changes.  A refactoring of the  
code that changes only the implementation but not the visible behavior of  
the code wouldn't require a new test.

In reality I think most projects will fall somewhere in the middle, in  
which you start with the top-level spec, but then intermediate specs wind  
up being created, either implicitly or explicitly as the code design gets  
worked out.  And you may in fact wind up writing test for those  
intermediate layers.  But the deeper you go into the code, where there's  
an increased possibility that some major refactoring might occur, the less  
likely it is IMHO you'll be bothering with a unit test for that part of  
the code.

In the end, it's not really an either/or sort of thing.  It's a matter of  
where you put your focus.  In the end, you wind up doing varying amounts  
of work in different parts of the project, and the main question is where  
do you find it most valuable to invest the most effort?  IMHO there are no  
right or wrong answers here, but rather answers that fit the developer or  
team best according to their own needs, as well as their own strengths and  
weaknesses.

So, sure...you might wind up rewriting your tests because something  
changed.  But so what?  If that means you spend less time on something  
else, and especially if it means that the rest of the code is much more  
likely to be correct, that seems like a fair trade-off.

The trick is to make sure you're really getting the benefit of that  
trade-off by writing good tests.  Garbage in, garbage out.  :)

Pete

This is the purist approach and it has both merits and detractors. Most of
the detractors are paradigm shifts rather than actual impediments.

If you do a code first, design second approach, this is a risk. If you take
time to brainstorm your application and figure out use cases, flows, etc.,
there is very little danger. Organization is the key, but then again, you
should not be building an application that you do not understand.
Unfortunately, this is VERY common in the industry, as managers try to limit
design time, throw out specs that are worthless, etc.

BTW, refactoring, for the most part, does not break tests, as the majority
of it is either a) refactoring out duplicate code or b) refining current
code. If you are changing interfaces, etc., you are not really refactoring,
you are altering. Let's take an example:

if(x=1) {}
elseif (x=2) {}
elseif (x=3) {}
elseif (x=4) {}
else {}

Each of the conditions has to be walked, which is inefficient. A common
refactor would be to change to a switch (Select ... Case) in VB.

switch(x)
{
   case 1: {}
   case 2: {}
   case 3: {}
   case 4: {}
   default: {}
}

This creates a state machine. That is a refactor. But, note, that there is
nothing happening here that changes my public interface, so the test still
works.

In fact, since most refactoring is trying to improve, not alter, code, NOT
having tests is a major detriment, as your tests, when written properly,
protect you against new bugs in old code.

Does refactoring ever break tests? Certainly. But, more often than not, it
is because your refactoring revealed a flaw in your test. Either you were
running the test for the wrong behavior or you have set up an overly
optimistic test, or similar.

Yes. You are missing the core of TDD.

1. Design - Determine what you are building
2. Decide - Agree on functionality to be built
3. Divide - Break work down into bite sized chunks
4. Write Tests - write a test on the expected behavior
5. Write code to pass the test - red to green
6. Refactor - remove any "code smells" (repeat code being the most common)

If you start with step 4, you will probably end up rewriting your tests as
you really have no clue what you are building. In that case, return to step
one. I can even add a pre-step, which is brainstorm.

If you want to get a good idea of how to start design for customer facing
apps (and I include internally facing apps here), you can watch the free
user experience videos at http://sessions.visitmix.com (need to have
SIlverlight installed). Some really nice sessions on design are UX04, UX05,
UX06 and UX07 (in that order), which are videos from Adaptive Path. The
middle of each is boring, as people are doing exercises, so fast forward to
the last 10-15 minutes when they start that.

Another thing to consider is unit tests are just that. They test a single
routine. You can expand this a bit, but if you are system testing, your
tests are too broad.

Let's take an example, which you might be thinking fits your "problem" with
TDD and why it does not.

You have a test that tests a User object. In your application, you will pull
the information from the database and diplay on a web page. Something like:

ASP.NET page
Welcome <asp:Label id="nameLabel" runat="server"/>

Code behind
nameLabel.Text = user.UserName;

You have a user object that is filled by some facade method. A quick stub
would be something like:

public static User GetUserFromId(string userID)
{
   //Stuff to test id and pull user object from database here
   return user;
}

So, you set up the following test (using Visual Studio unit test format):

[TestMethod]
public void TestGetUserFromIdSuccess()
{
   string userID = "G5F765";
   string expectedName = "Greg Beamer";

   User actual = UserFactory.GetUserFromId(userID);

   Assert.AreEqual(expectedName, actual.Name, "Name is different");
}

Suppose, however, that the test data no longer contains the same name for
that user. It fails. But, you are not supposed to be testing the database
retrieval at the business layer. You should be injecting the dependency, so
it always returns the right name. This may sound like "cheating", but you
are only testing the code in THAT routine.

Now, if you change the entire business layer and how you retrieve data, you
will break the application. But that is more likely to happen if you have
not designed it up front, at least in most instances.

I disagree. In fact, I have used TDD for years now and find that 90%+ of my
tests are still around. There are a few that have changed, but if you design
first and then code, you find that you eliminate a lot of useless rabbit
holes before you even start coding.

*************************************************

Correct. Or written by someone other than the person writing the code.

Otherwise:
  implementation problems => tests => design
for TDD or:
  tests will tent to test what the code does instead what it should do
for more traditional unit tests.

A refactoring in the low level sense should not require unit tests to
be rewritten.

A change in design (which you can call refactoring at the high level)
will require a change in unit tests.

It should not happen that often.

And if it does happen, then I would expect rewriting unit tests
to be a very small fraction of the work added.

I don't see it as a problem.

Arne

PS: I am not particular TDD oriented. I see the main advantage of
    extensive unit tests to show up after the code is developed
    and enter maintenance mode.