¿Alguna vez has estado trabajando en un proyecto y te has encontrado con la necesidad de probar métodos o clases que están marcados como internal? ¡Seguro que sí! En esos momentos, puede ser un poco frustrante no poder acceder directamente a ellos desde tus proyectos de test. Pero no te preocupes, hay una solución sencilla y elegante para este problema: el atributo InternalsVisibleTo.
¿Qué es InternalsVisibleTo?
Primero, un poco de contexto. En C#, el modificador de acceso internal se utiliza para hacer que miembros de una clase (métodos, propiedades, etc.) sean accesibles solo dentro del mismo ensamblado. Esto es genial para mantener la encapsulación, pero ¿qué pasa cuando quieres escribir pruebas unitarias para esos miembros?
Aquí es donde entra en juego el atributo InternalsVisibleTo. Este atributo permite que otro ensamblado tenga acceso a los miembros internal de tu código. Dicho de otra manera, con InternalsVisibleTo le das permiso a tu proyecto de test para que vea y acceda a esos métodos y clases internos que de otra forma estarían ocultos.
Cómo habilitarlo en tu proyecto
Habilitar InternalsVisibleTo es súper fácil y tienes dos maneras de hacerlo:
Opción 1: Usando el archivo AssemblyInfo.cs
Abre tu archivo de proyecto principal (el que contiene el código que quieres probar).
Agrega el atributo InternalsVisibleTo en el archivo AssemblyInfo.cs, o si no lo tienes, en cualquier archivo .cs de tu proyecto. Este atributo toma como argumento el nombre de tu proyecto de test.
Aquí tienes un ejemplo:
using System.Runtime.CompilerServices;
[assembly: InternalsVisibleTo("MiProyectoDeTests")]
En este caso, "MiProyectoDeTests" es el nombre del ensamblado de tu proyecto de pruebas. ¡Y ya está! Con esta línea, tu proyecto de pruebas puede acceder a todos los miembros internal de tu proyecto principal.
(Opcional) Protección adicional con claves fuertes: Si estás usando claves fuertes (strong naming) en tu proyecto, necesitarás especificar también el token público en el atributo. Algo así:
[assembly: InternalsVisibleTo("MiProyectoDeTests, PublicKey=0123456789abcdef")]
Opción 2: Usando el archivo de proyecto (.csproj)
Otra forma de habilitar el acceso a miembros internal es configurando el archivo de proyecto (.csproj) de tu proyecto principal. Este enfoque tiene la ventaja de mantener la configuración en un solo lugar, lo cual puede ser más cómodo en proyectos grandes.
Abre el archivo .csproj de tu proyecto principal.
Agrega un nuevo ItemGroup con la siguiente configuración:
<ItemGroup>
<InternalsVisibleTo Include="MiProyectoDeTests" />
ItemGroup>
Este bloque le indica al compilador que el ensamblado MiProyectoDeTests puede acceder a todos los miembros internal de tu proyecto principal.
(Opcional) Claves fuertes: Si tu proyecto principal está firmado con una clave fuerte, puedes añadir el token público aquí también:
<ItemGroup>
<InternalsVisibleTo Include="MiProyectoDeTests" PublicKey="0123456789abcdef" />
ItemGroup>
Ventajas de usar InternalsVisibleTo
Lo bueno de esta técnica es que no comprometes la encapsulación de tu código en producción. Todo se mantiene tal como lo has diseñado, pero ahora tienes la posibilidad de escribir pruebas más completas y precisas. Además, no tienes que recurrir a técnicas como la reflexión, que aunque funcionan, pueden ser un poco engorrosas y menos eficientes.
Conclusión
Habilitar internal en proyectos de test es una práctica que puede ahorrarte mucho tiempo y dolores de cabeza. Ya sea que elijas hacerlo a través de AssemblyInfo.cs o directamente en el archivo .csproj, es una solución sencilla pero poderosa que te permite mantener la encapsulación y al mismo tiempo escribir pruebas unitarias efectivas. Así que la próxima vez que te enfrentes a un método o clase internal que necesitas probar, ya sabes qué hacer.