Automating "All" Tests

I wrote on the same discussion list:

"Automated test suites, have the great gift of fast feedback: I call them
break detectors. The more break detectors you have, the better the
feedback, but there can be cases with too many tests. Is there such a
thing like too many tests: yes, because tests are code after all and the
rule of running from complexity applies with tests also. Too many tests,
can be a case where you have many tests and they are hard to change. A
suite of tests ensures in agile projects the possibility to make changes
faster, to have more courage. When this advantage is gone, and it is hard
to change the tests, you have duplication in them, they are too complex,
then there's a problem. This kind of problems cannot be explained to
someone that never heard of agility, or has little idea.

Automated tests can be a great weapon. But as a friend of mine said, the
more powerfull the weapon the bigger the chances are for you to kill
yourself with it, if the attention doesn't counterbalance the power.

Probably how much automated testing should there is a complex matter of
balance. Automated tests should be used with a very clear goal, and always
keeping in mind that they can become easily a problem themselves if not
used right."

Scott, to Ron's list:
* No one really automates all tests
* No one really could automate all the tests ...
* It would be cost prohibitive to do so
* There are many important examinations of the product that can only be carried out "by hand" ...

I would add:
* Even if they tried to "write all tests", what team can afford to maintain them?

deb

[...]
I would add:
* Even if they tried to "write all tests", what team can afford to maintain them?

deb

So, now that we are all agreeing with Ron - anyone know other good references on the subject? I'm relatively new to the subject myself. --deb