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?](https://stackoverflow.com/questions/3443755/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. 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.
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.