With languages like Java, the inherent rigidity requires all sorts of ugly ugly reflection hacks, and factory, impl, interface proliferation to get the flexible testing behavior you get for free with more dynamic languages.
If you need to add new language primitives to make unit testing practical, maybe your language is too cumbersome.
It's often better to go quickly go down a path and see how it plays out, opposed to sitting there and thinking about something for a long time. When you move forward, problems and things you didn't think about become obvious.
In Haskell, you do not fight the compiler either. With practice, you will find that the few type errors the compiler returns to you are legitimate: Wrong calling conventions, typos, API misuse, returning nonsense in a specific case and so on. I have, perhaps, some 5 errors per 100 lines of Haskell code I write that the compiler quacks on. It is equally bad moving dynamically typed programming idioms to Haskell as it is moving statically typed programming idioms into, say, Python.
Though a lot of my complaints about Haskell's type system could be alleviated with a good integrated refactoring tool. If I had one-command operations to:
a.) Convert a plain function to a monadic one
b.) Change the signature and stacking order of a large stack of monadic transformers
c.) Add a new alternative to an algebraic data type, and track down and fix all functions that use it.
d.) Add a new parameter, at an arbitrary position, to a function.
e.) Change a straight return value to a Maybe.
f.) Add a new field to a record or tuple type.
Then I'd find Haskell's type system much less oppressive. What's the status of Leksah these days?