MDD - Mock Driven Development

I'm a 10 year Java veteran and try to be very open to changes in the way the language is used. However, I've recently been introduced to a new pattern which I'm having trouble seeing as necessarily a good thing. I'll call this pattern Mock Driven Development (MDD).

Basically, it's a form of OO but removes any and all programming patterns which are not conducive to making any and all code mock-able in unit tests. While I'm all for mocking being used as a powerful way to simplify unit tests, basing your entire programming patterns off of the abilities of the concept of how mocking is done seems to raise my "anti-pattern" red flag.

One example is that since *most* mocking frameworks don't really support mocking static/final/private methods all that great MDD says to never use them. So what you end up with is code that looks like this:

Code:

---

ServiceDoSomethingDelegate delegate = new ServiceDelegate() {
    public void delegate(...) {
        // do delegation
    }
};
service.doSomething(obj, delegate);

---

Because having private or static methods inside your service is inherently bad, you end up instantiating and, IMO, spraying all sorts of objects around (most of which are callable). It lends itself towards a much more functional and callable way of programming. Don't get me wrong, I'm hip to the whole functional way of doing things, but to impose this kind of wide-spread development due to the initial mantra of "if it can't be mocked then don't do it" seems too dogmatic for me.

Am I just being a cranky old fart of this, or has anyone else seen patterns emerge like this?

Does the technique honestly say "no private methods"?
I can understand limiting static methods to fairly simple things (eg the Math class), though not entirely removing them, but private ones? Sorry, that's silly.

There is a style that does feel private methods should be unit tested, but I'm definitely not in that group, and have never worked anywhere where that applied. After all, private methods are inherently very volatile, so having unit tests for them would be a nightmare. Refactoring (it strikes me) would become a serious chore.

Having said all that, I do write stuff with a view to testing, and since I'm usually using Spring in some shape or form then that tends to be a natural result.