Métodos internal, unit testing y el atributo InternalsVisibleTo

Los miembros y métodos en C#, pueden gozar de varios modificadores de acceso. Amigos míos, no solo de públicos y privados vive el hombre.

Hoy vamos a hablar de uno de ellos.

El modificador de acceso internal.

El modificador de acceso internal, es aquel que nos va a permitir acceder a la clase, miembro, método etc. desde el propio ensamblado.

Que quiere decir esto, pues implica que dentro de un mismo ensamblado vamos a poder acceder a una clase internal como si de una clase pública se tratara, pero fuera de este ensamblado esta clase no va a ser accesible ya que no la estamos exponiendo.

Trabajar con clases internal, considero que es una buena práctica, ya que en los distintos assemblies que vamos generando, únicamente vamos a exponer lo que consideramos fundamental, de manera que el susodicho assembly, queda mucho más encapsulado. Además si el software que estamos desarrollando va a ser distribuido para que lo usen terceros, todavía tenemos más razones para usar este tipo de modificador de acceso.

Los métodos internal y las pruebas unitarias (unit test) o como acceder a aquello que no expones.

Hasta aquí, me encanta el modificador de acceso internal, pero ¿qué ocurre cuando tenemos que crear las pruebas unitarias para métodos internal?

Pues muy sencillo, que como no estamos exponiendo muchas clases y métodos, resulta que no lo podemos probar.

Jajajajaja, bueno, esto no es así exactamente aunque sí que es verdad que es una de las primeras cositas que encuentras (si tu desarrollo es TDD compliance claro).

La realidad es que no estamos exponiendo muchas clases por lo tanto no deberíamos poder probarlas, pero el Framework de ASP.NET precisamente cuenta “un mecanismo” para realizar esto.

El atributo InternalsVisibleTo.

Pues si amigos míos, el Framework de ASP.NET cuenta con atributo llamado InternalsVisibleTo que nos va a permitir acceder a clases internal desde assemblies externos.

El código necesario sería el siguiente:
[assembly: InternalsVisibleTo("MiAssemblyName.Test")]

Y esto, tenemos que colocarlo en el AssemblyInfo de nuestro proyecto.

Nada más por hoy mis druguitos. Aquí se acaba esta sesión de ultraviolencia. Os dejo con The XX, que además de ser unos chavales que hacen una música que me recuerda a los títulos de crédito de documentos tv, son geniales.

Anuncio publicitario

Los métodos extensores.

Los métodos extensores, nos permiten “extender” la funcionalidad de una clase sin que sea necesario usar herencia o polimorfismo pudiendo añadirle funcionalidad a clases “core” del Framework.

Hay que tener en cuenta, que estos métodos aunque son muy útiles, en ningún caso pueden sustituir a la herencia de clases.

Para crear un método extensor, necesitamos un código tal como el siguiente:

public static string ToMD5(this string str)
{
MD5 md5 = MD5CryptoServiceProvider.Create();
ASCIIEncoding encoding = new ASCIIEncoding();
byte[] stream = null;
StringBuilder sb = new StringBuilder();
stream = md5.ComputeHash(encoding.GetBytes(str));
for (int i = 0; i < stream.Length; i++) sb.AppendFormat("{0:x2}", stream[i]);
return sb.ToString();
}

Como veis, el metodo extensor, ha de ser estático y ademas, va a recibir siempre como parametro el objeto que lo llama, a este objeto tenemos que añadirle el parametro this.

Así de facil y sencillo. Este tipo de metodos, los había usado con JavaScript y ActionScript, y ahora, mis drugitos, los podemos usar con C#, toda una maravilla.

Bajate el código y échale un ojo, y cuando uses este tipo de metodos, cuidado, ten en cuenta que no estan pensandos para sustituir la funcionalidad que nos proporciona la herencia, y como bien dicen aquí, es interesante agruparlos en un mismo namespace (que en una única clase).

Nunca han sido santos de mi devoción los planetas, aunque desde hace unos días, no paro de escuchar su “corrientes circulares en el tiempo”, canción mucho más madura que la mayoría de sus exitos.