Is it considered bad practice to use InternalsVisibleTo for Unit Test Code?

Question

Sample code in framework\'s AssemblyInfo.cs:

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo
                          (\"Test.Com         


        

Answer 1

Personally I think it's fine. I've never gone along with the dogma of "only test public methods". I think it's good to also have black box testing, but white box testing can let you test more scenarios with simpler tests, particularly if your API is reasonably "chunky" and the public methods actually do quite a lot of work.

Likewise, in a well-encapsulated project you may well have several internal types with only internal methods. Now presumably those will have a public impact so you could do all the testing just through the public types - but then you may well need to go through a lot of hoops to actually test something that's really simple to test using InternalsVisibleTo.

Answer 2

I think it's perfectly reasonable to do that.

I find it very useful for dependency injection. If I have a class with a constructor that takes in a few dependencies to allow it to be unit tested I often mark it internal and expose it in my unit test project. Then I'd have a public (parameterless, or at least with far fewer parameters) constructor. This keeps the public interface clean and still allows for testable code.

Answer 3

InternalsVisibleTo could be useful if you need to test sub parts of your API which you don't want to expose.

However, testing through the public API is preferable since it makes refactoring interal APIs easier. Use InternalsVisibleTo with care and only when appropriate, e.g. the size of the API is significant.

Answer 4

No, it is not considered bad practice. There is no other way, if the classes you want to test are internal to your assembly for good reasons. Just not testing them would be a lot worse.

Answer 5

I would say it is bad practice because if you have used the SOLID principles then you really shouldn't have to use "InternalsVisibleTo". However i know in the "real world" you get all sorts of code.....so the pragmatic approach is best.

Also "InternalsVisibleTo" is not ideal in scenarios where you use obfuscation. Obfuscators tend to obfuscate the "internal" stuff. Therefore any external dll that attempts to reference the internals of an obfuscate dll will fail. You can obviously configure the obfuscator to ignore externally referenced items, but that would refuce the effectiveness of any obfuscator.

In my opinion, avoid "InternalsVisibleTo" if you can. But if you have to use it then theres something wrong with how the code is structured (which you tend to get a lot off)

Answer 6

No, when used correctly, because in some scenarios its necessary. For instance, you have unit test A that needs to test a public member of assembly B that uses some internal type also defined in assembly B. The unit test needs this type, thus you must use InternalsVisibleTo.

It is also useful for protecting code. A for instance is an Activation assembly. You may only want one module in your solution to access your activation assembly, and prevent anyone from adding a reference to it and calling methods. You can make the types and members internal, expose them only to a signed assembly with a public key token, and its hidden from the rest of the world.