Is it worth to change class access modifier (no or internal originally) to public for unit testing purposes if unit tests resides in another assembly? private or internal indicates that class is encapsulated in the assembly. If answer is no what is the workaround in C#?
1 Answers
The easiest approach to this question is to apply Test-Driven Development (TDD), which is more of a feedback mechanism than a design approach.
When using TDD, you write the test first, so it should be immediately clear if your System Under Test (SUT) is hard to test. This informs the design of the SUT in such a way that it becomes easy to test.
This doesn't mean that you're allowed to compromise Encapsulation. You should still adhere to good Object-Oriented Design principles.
If done this way, nothing ought to exist that isn't covered by tests. You may have internal classes, but they're indirectly tested via other, public classes' public members. Never test internals. If you do that, you're coupling your tests to those internals, which means that they might as well have been public.
[InternalsVisibleTo]
might help you. Making everything public is a bad idea. And you should be able to cover all your code by using the public API. If you can't reach it from the public API, you might as well delete that code. – Blorgbeard