0
votes

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
Don't test the private/internal method - test whatever uses the private/internal method.D Stanley
it is class access modifier - not method. Like public class Foo. Not testing the whole class is not acceptable in my case.user5059319
I found this in ones blog: "There is a school of thought which espouses the policy that only public api s need to be unit-tested. This is not true - I firmly believe that all your methods and behaviors need unit testing."user5059319
Maybe there are some tricks - in C++ for example, to test protected method I can inherit from tested class without changing tested code. In C# I can't inherit from tested class from another assembly if it is not public.user5059319
[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

1 Answers

3
votes

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.