关于私人方法的单元测试的问题

Question

In MSTest, the [Shadowing] attribute helps you to unit test a private method from another assembly. Here is the related link : What is the Shadowing attribute that the VS uses when it generates unit tests?

My questions are:

1. Should private methods be unit tested separately?
2. Is it a good (?) practice to change private method's accessor to internal just to make it available for unit testing in some other test project/assembly? (using InternalsVisibleTo )
3. If private methods get tested indirectly through the public method that calls them, can it be called "unit" testing?

Answer 1

1. No, private methods should not be tested. Your application will interact with public API only. So you should test expected behavior of your class for this interaction. Private methods is a part of inner logic implementation. Users of your class should not be care how it implemented.
2. No, it is not good. See above. You should test public API only.
3. You should test only public methods. You don't care if public method will call to private method or will not until test is passed. If test fails, fix implemetation. But don't test private methods anyway.

UPDATE (how to define what to test): Ideally (in test-first approach) test is the first user of your class. When you write test, you try to imagine how users will use your class. Users will not interact with private methods (Reflection is cheating). So and your test, as first user of your class, should not interact with private methods.

Answer 2

To answer your questions briefly:

1. In general, they shouldn't. Most of the times, your private bits will be tested while testing class contract/public API. For the times this is not possible, testing private method is unit test just as anything else.

2. This is fairly common. While changing visibility might be considered bad idea, it's not as bad when it changes only to internal. However, in approaches like TDD, the need of testing usually drives your desing in such way that "hacks" like this are not needed. But like I said, it's fairly common - you shouldn't worry too much about it, unless it gets to ridiculous levels (say, entire private parts of classes exposed).

3. It is unit test as long as it tests single unit (or, one logical concept ) of your class. Private methods more often than not are created as a results of refactorings in public parts, which most of the times will be targeted by the single unit testing. If you feel your private method is not longer an unit , it might be a refactoring call.

Also, I suggest having a look here , here and here .

Answer 3

I would preffer to exercise all the private methods thru the public available calls. There must be a path to execute each private line from a public call and if it is not there you can delete that code.

Using internal instead of private could end with a big mess, I won't use that approach.

Answer 4

As a Java developer, I do. I don't change access levels, either. I use reflection to get access to private methods. I don't have to grant it to my users, and I don't have to show them my unit tests.

It's a dirty secret of Java: you can always circumvent access restrictions with reflection. I don't know if it's also true of C# and .NET, but you can look into it to see.