Q:

Implementing a protected parameterless constructor for unit testing

If I have a type with a big-old (lots of params) constructor, is it a valid approach to implement a protected parameterless constructor simply for the purposes of creating a derived "Fake" type to use for stubbing in unit tests?
The alternative is to extract an interface, but this is not always desireable in a codebase you do not have full control over...

A:

It's not ideal, but it is valid.
To quote a couple of people who know more about this than me, in The Art of Unit Testing, Roy Osherove talks about unit tests being like a user of the code, and as such providing access specifically  for them is not necessarily a bad thing.
And in Working Effectively with Legacy Code, Michael Feathers discusses several such techniques, pointing out that making things protected for testing can be better than making them public, although it's not necessarily the best way to do things.  (In fact I'd recommend you read that book if you are working with legacy code, as it sounds like you are).
I think it depends what sort of code it is - if it's a public API where people are likely to take protected access to mean it's designed to be overridden, it's probably a bad idea, but on a typical business app where it's pretty obviously not meant to be overridden, I don't think it's a problem.  I certainly do it sometimes in this situation.

