0

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#?

  • 2
    Don't test the private/internal method - test whatever _uses_ the private/internal method. – D Stanley Sep 16 '15 at 22:58
  • it is class access modifier - not method. Like public class Foo. Not testing the whole class is not acceptable in my case. –  Sep 16 '15 at 23:01
  • 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." –  Sep 16 '15 at 23:03
  • 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. –  Sep 16 '15 at 23:06
  • 5
    `[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 Sep 16 '15 at 23:06
  • @Blorgbeard My point exactly. – D Stanley Sep 16 '15 at 23:17
  • @Blorgbeard. Works, looks promising in my test project. Could be issues with strong names - will look tomorrow in office. Thank you. –  Sep 16 '15 at 23:24
  • http://stackoverflow.com/a/1093481/126014 – Mark Seemann Sep 17 '15 at 05:47
  • http://programmers.stackexchange.com/a/199122/19115 – Mark Seemann Sep 17 '15 at 05:47
  • OP: Stay well away from `InternalsVisibleTo` - you do not have the unique codez that require it, no matter how tempting it can be to view it that way - figure out how to lay stuff out properly testing only through the front door -- it's just going to be a world of pain you'll regret (problem is it may be up to a year before you figure that out). (I agree 100% with Mark's answer but just wanted to say it in a different way in case you were wavering :)) – Ruben Bartelink Sep 17 '15 at 09:05
  • [InternalsVisibleTo] is good answer. Functional tests can use front door. Unit tests use mocks focusing on tested target. And it is better to separate regular and test code in separate binaries. So something like [InternalsVisibleTo] should exist. Something that introduce exception to common rule, restriction. Blorgbeard please give the answer. –  Sep 17 '15 at 22:19

1 Answers1

3

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.

Mark Seemann
  • 225,310
  • 48
  • 427
  • 736