Unit Testing y acceso a clases declaradas como internal (II)

En una entrada anterior, indicaba una forma de abordar una solución para probar unitariamente o acceder si acaso, a clases declaradas como internal desde otro ensamblado, ya sea desde una aplación de pruebas unitarias, o bien desde otro ensamblado concreto.

Si me centro únicamente las pruebas unitarias, existe una forma adicional a la que mostraba en aquella otra entra y que podemos usar también en nuestros desarrollos para acceder a nuestras clases internal.

Esta forma consiste en utilizar las directivas de compilación.

De hecho, nuestra clase internal quedaría de la siguiente forma:

namespace InternalSampleClass
{
#if DEBUG 
    public class InternalClass
#else
    internal class InternalClass
#endif
    {
        public string Get()
        {
            return $"{nameof(InternalClass)} from {nameof(Get)}";
        }
    }

}

Otra forma compatible de la anterior sería:

namespace InternalSampleClass
{
#if DEBUG 
    public
#else
    internal
#endif
    class InternalClass
    {
        public string Get()
        {
            return $"{nameof(InternalClass)} from {nameof(Get)}";
        }
    }

}

De esta forma, en DEBUG nuestra aplicación tendrá un comportamiento de clase pública, mientras que en RELEASE tendrá un comportamiento internal.
Como contra de esta técnica, está la posibilidad de que sin querer hagamos referencia a una clase internal que en modo DEBUG no dará ningún problema, pero que en RELEASE dentro de un entorno de integración continua, seguramente nos devuelva un error de compilación.
La única norma no escrita pero obligada en este caso, es que no debemos subir nada al repositorio de código que no haya pasado la compilación local DEBUG primero y RELEASE después.

Es una forma más cómoda de no dar permisos a ningún ensamblado en el fichero AssemblyInfo para que acceda a nuestras clases internal.

Happy Coding!