0

I am writing my UnitTests in a seperate Project from my Project under Test. To be able to test Internal classes/members I use the [InternalsVisibleTo] Attribute in my Project Under Test.

#if "BUILD_CONFIGURATION"
[assembly: InternalsVisibleTo("Tests_ProjectUnderTest")]
#endif

Following question arises:

Which Build configuration should I use for Unit Tests? The Internals shouldn't be visible in my released code, so #if RELEASE is not possible. On the other hand #if DEBUG doesn't really test what I want to release. Should you have a distinct UNIT_TEST-Configuration? Or how would/do you do this?

joerg
  • 717
  • 2
  • 8
  • 18
  • 4
    Just leave the `InternalsVisibleTo` attribute in there all the time. At the end of the day, if people want to get at your internals, they can do it through reflection anyway. – James Thorpe Aug 13 '15 at 08:51

1 Answers1

0

I don't usually make the [InternalsVisibleTo()] attribute conditional, since the internals are only ever made visible to the named assembly. You can beef up the security of that by strong-naming the assemblies, so then no-one can 'fake' your unit test assembly. However, if you're that concerned about this, you should probably be obfuscating your assemblies anyway, otherwise reverse engineering is trivial. I generally take the attitude that private/internal is a statement of intent and not a security feature, since it can always be circumvented using reflection.

I generally unit-test my debug configuration, because I want to see the diagnostic output in my unit test results. This may depend on which runner you use, I use the ReSharper runner and it captures debug/trace output into the unit test window. Since the trace verbosity is reduced in my release builds, I prefer to unit test the debug builds. I think this is a judgement call, though.

Tim Long
  • 13,508
  • 19
  • 79
  • 147