chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male

Is the visibility of tested methods important?

We are having quite a discussion lately within Typemock about theimage importance of the visibility of tested methods.

For example, should it really be harder to test a private method?
If it is harder, then many developers will opt to change the scope of the tested method to public, even if business wise, it should stay private. If Visual Studio allowed using private methods from test projects (as it does with internal methods) then developers can choose to invoke private methods and the test will not pollute the design. (I know that Visual Studio does have a private accessor, but it is still awkward.)

The same goes with mocking or isolating. During the test, there are many times that we don’t care about some calls and want to fake those out.

Should we care if these calls are static, public, protected or private? If we just don’t care about those interactions (known as stubbing) should we care about the visibility of these methods?

On one hand we are saying that it does matter and that we need to explicitly say this when arranging our tests.

example of a new API with a difference between scopes

On the other hand we should keep a minimum API and that will lead us to.

My current take is that the visibility issue is a technical one and not a real API issue, I think that the biggest issue developers have is over-specified tests.

What would make developers fall into the put of success is the following:

This will fake all calls to HttpWebRequest, and will automatically recursively fake all ‘chained’ methods, so  HttpWebRequest.GetResonse() will return a fke Response, like a recursive NullObject Desgin.

What is your take?