Would you rather make private stuff internal/public for tests, or use some kind of hack like PrivateObject?

Question

I am quite a beginner in code testing, and was an assert whore before. One thing worrying me in unit testing is that is often requires you to make public (or at least internal) fields that would have been private otherwise, to un-readonly them, make private methods protected virtual instead, etc...

I recently discovered that you can avoid this by using things like the PrivateObject class to acces anything in an object via reflection. But this makes your tests less maintainable (things will fail at execution rather than compile time, it'll be broken by a simple rename, it's harder to debug...). What is your opinion on this ? What are the best practices in unit testing concerning access restriction ?

edit : consider for instance that you have a class with a cache in a file on disk, and in your tests you want to write to memory instead.

Answer 1

You should never-ever have to

make public (or at least internal) fields that would have been private otherwise, to un-readonly them, make private methods protected virtual instead

• Making a private member non-private turns the object into a Leaky Abstraction (wikipedia) which is the cause of much weeping and wailing and gnashing of teeth. (wiktionary)

• Un-readonlying a field can make an immutable object mutable, which is nothing short of a disaster.

Your test should consider your object-under-test as a Black Box (Wikipedia), meaning that it should only be concerned with the public interface of the object-under-test, not with details of its implementation.

If an object cannot be sufficiently tested via its public interface, then you need to find ways to provide formal and useful extensions to its interface that would facilitate testing. For example, a registration system which only exposes a pair of Register()/Deregister() methods is what I call a Black-Hole Interface because information can only enter it but never leave. To fix this:

• The solution is most definitely NOT to expose its internal collection of registrants, so that the test can go peeking into that collection.

• The solution is to add an IsRegistered() method, even it will never be invoked by the application at hand; still, it is a formal and useful extension to the interface, it prevents the interface from being a black-hole interface, and incidentally, it accommodates Black-Box Testing.

The important thing is that changing the implementation of the object should not require you to change the unit test. In principle you should be able to completely rewrite the module under test, and reuse the existing test to make sure that the new version works exactly as the old version. This is only possible if the test is strictly a black-box test.

Amendment 2022-11-02 for further reading:

• michael.gr - White-Box vs. Black-Box Testing
• michael.gr - Incremental Integration Testing

Answer 2

In C# you can use the InternalsVisibleToAttribute to allow your test assembly to see internal classes in the assembly you're testing. It sounds like you already know this.

In most cases I'm only interested in testing the public API of my assembly. In a case where I want to do white-box testing of some unit, I move the code to an internal class, and make it a public method of that class. Then I can code a unit test for that class.

This lends itself well to dependency injection and the strategy pattern. You can abstract the method into an interface, inject the interface into your parent object's constructor, and just test that the parent delegates appropriately. Then you can test that the child object behaves appropriately. This makes everything more modular.

Answer 3

In my experience it is best not to expose the internals of your class specially for the test. Even though this may appear to make the test easier to write. The test is the first client of your class, so if it is hard to test your class through its public interface, it will probably be hard to use your class in other places too.

How easy the class is to test through its public API is feedback on how easy the class will be to use. Think of the tests partially as a way to prototype the usage of your class.

Try to consider why your test needs to sense something about the class that is not available through the public API. Perhaps your class is doing too much and needs to be decomposed into a group of co-operating classes instead? Then you can mock some of the collaborating classes to sense what the class under test is doing.

Try to apply the dependency inversion principal and introduce interfaces between your classes which you can mock in your tests. You can provide the collaborators to your test by using inversion of control.

Also consider applying the "tell don't ask" principal to help structure your class interface in a robust, loosely coupled, manner, where the right information is exposed and the rest is hidden.

Answer 4

Personally I prefer to leave the code I am testing as pure as I can and if the test code needs hacks (and in C++ nasty pointers etc) I am happy to do that.

Answer 5

The visibility of your code has nothing to do with your unit tests!

You make your methods private not with the purpose to hide them from testing and you don't make them public to expose for testing, right? This is your implemenation that is essential here, not the tests -- those server as proof of your code, but they are not your code.

There is a plenty of ways to enable access to hidden (private or internal) methods and properties. Many test frameworks and IDEs (for example, Visual Studio) support you here by generating everything needed for the access, you only have to author your test cases. So, why worry? Better keep your code clean and neat.