Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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…
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.