I'm pretty far into the extremist side of TDD, and I'll say that there is a thing as TOO many tests. Your test suite needs to run fast to be really useful.

If you have thousands of full stack integration tests that takes an hour to run, you're not going to run them as often as you should be, if at all, ad might as well delete them.

If they are run by a continuous integration server on check in, it kind of doesn't matter how long they take to run.

Completely false. You need to know that your change doesn't break the build, and if you wait a long time, you will have mentally switched gears when informed of the breakage. This is a big productivity sink.

(What's worse is when changes come in faster than the CI system can run the tests. Then you don't know which change broke your build because many changes were tested at once.)

Anything longer than 10 seconds is too long, in my opinion. As soon as you can get up to get coffee while your tests are running, you've lost a lot of productivity. (I recently finished a project where the tests took about ten minutes to run. That meant I could only change code 50 times per day. If the tests had taken 10 seconds, I would have been able to be make 300 changes per day. That's a 6x productivity increase right there.

Fast running test suites are absolutely essential.

That's not strictly true: you'd still like to get reasonably quick feedback, especially if you're trying to make a release.

It's also nice to be reasonably confident that your commit won't break the build, for which you should probably run a good chunk of the tests before committing.

There are some workflows (Gerrit springs to mind) where you can let the CI server work on your code without breaking anything else, but even then there's a cost to the context switch when a test failure means you have to return to a piece of code you thought you'd finished.

Then they need to be moved to a different place, at least. Tell your CI server to use them, but more them out of the way for normal developers.