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?
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.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments