InternalsVisibleTo unit tests

[krwq]

What do you think, is it ok to use InternalsVisibleTo in unit tests or is it better to do special (sometimes quite heavy) set up?

My vote is for "it is ok" as I believe it would make tests much cleaner, easier and faster and it doesn't make sense to over complicate just for the sake of not using InternalsVisibleTo.

[bpschoch]

IMHO, it depends on the philosophy of testing. If unit testing is to only test the public interfaces, then there is no need to access internal items. On the other hand if testing is there to exercise all of the internal workings of a component, then perhaps it's justified.

I'm wrestling with that issue right now with the testing I'm setting up with System.IO.Pipes. So far I'm only using public interfaces, however it's not possible to really to get full code coverage without accessing some of the internal components.

[krwq]

@bpschoch, If some code paths are not accessible that means that we have some dead code which in most cases we can remove. If it is accessible but the set up is complicated or quite heavy (consuming unnecessary resources or takes a long time or really long piece of code initializing) my opinions is to use InternalsVisibleTo. If accessible and set up is fairly easy (few lines of code which do no heavy ops) always use that.

[weshaggard]

I generally diss-like InternalsVisibleTo just for the purpose of code coverage. I believe it causes inconsistency and unnecessary coupling that makes the tests too fragile. For example if you call an internal API you are taking a dependency on a particular implementation detail that may get you into a state that isn't consistent with the state you would be in if you only called through public APIs and so you aren't actually testing the true behavior. As for the coupling you are tying the set of tests to one given implementation. Using the public API contracts allow you to have a consistent set of tests that can be ran on the various implementations (i.e .NET Core, .NET Framework, .NET Native, etc) to ensure they behave consistently and by depending on internals you restrict the tests to only one such implementation.

[sharwell]

@weshaggard From the perspective of public APIs, you are absolutely correct. However, public APIs are not the only boundary within an application or component for which you want to have well-defined and well-tested behavior at the boundary. IVTs for testing are required for testing internal APIs representing a component or module boundary (e.g. an internal interface which another developer might interact with, but not know the implementation details for that interface). Regardless of what code coverage tooling says, a test suite is crippled if it's incapable of testing internal abstractions.

📝 Note that I'm not advocating for fine-grained unit tests here. That is a totally separate discussion.