I don't even like to use constants, for the same reasons. I prefer a public method to a private method. A lot of times I'll write a class and make heavy use of public & private. Then during re-factoring, I will find a new home for all the private methods, so I can get them "out of the way" but also bring them into my public API, test them as they evolve to be more complex. What starts out as a constant eventually turns into a 1,000 lines of code when the customers are done with ya. lol
I do have lots of static stuff in my own code bases. But I recognize that as one of my flaws as a programmer, and I am constantly trying to better myself.
Its not just for testing either. Maybe you want the fake finder for a test? Maybe the client wants an RSS finder? You should just be able to change code just to change it, because often you'll end up needing to. When I write an "export" I get a flury of emails saying thats cool, can you make it export into "xyz format"? A successful application is going to have a LOT of growing pains. A few hours spent doing it right the first time pays off when you find out its limiting your sales a year later.
The way I look at it, if its well tested, its good code. Static code causes a problem in unit testing because its inherently bad code. Anything that causes pains in your tests, will eventually cause you bigger pains with your clients. The tests are not causing the pains the bad code is

You know in an MMorpg as you walk around parts of the "map" light up as you discover new areas in the game? Its kind of like that. The tests are just illuminating problems that already existed. Its letting you see the problems, stare the beasts in the face and giving you the opportunity to sleigh them now. So whether or not you do unit testing you really show use discretion with the "static" stuff.