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.

Anuncios

TDD, Unit Testing y Code Coverage

Todo desarrollo de software que se precie debería realizarse según las directrices del TDD (Test Driven Development) o Desarrollo Orientado a Pruebas, ya que nos va a permitir crear un código más mantenible y escalable.

Esto no es algo nuevo, al contrario, y la verdad es que está bastante trillado, pero siempre es bueno recordarlo ya que lo considero una de las mejores prácticas para el desarrollo de software.

Las pruebas unitarias son, más que útiles, fundamentales ya que nos permiten trabajar de una forma desacoplada y nos ayudan a estructurar y encapsular nuestro código. Pero una vez que las tenemos en verde, ¿Cómo podemos saber qué es lo que se está probando y si están bien hechas?

Aquí es donde entra el Code Coverage.

El code coverage como medida de calidad de nuestras pruebas unitarias, por lo tanto de nuestro software.

El Code Coverage, es una medida que nos va a permitir conocer el porcentaje de ejecución de nuestro código, tras haber ejecutado una batería de pruebas.

De esta medida, podemos sacar varias conclusiones:

  1. Podemos necesitar más pruebas unitarias.
  2. Hay código que hemos creado, que nunca se va a ejecutar, por lo tanto no es necesario y sobra.

El Code Coverage, no es necesario que este al 100%, ya que para conseguir esto, quizás tengamos que realizar pruebas unitarias que realmente no sean tales o no sean muy útiles (por ejemplo que estemos probando el Framework en lugar nuestro código), pero sí que es verdad que cuanto más cercano sea al 100% mejor.

La buena práctica, es trabajar con pruebas unitarias, y usar el code coverage como métrica de la calidad de nuestro software y eficacia de nuestro equipo, ya que lo interesante es ver como el code coverage va creciendo (o por lo menos va manteniéndose) iteración tras iteración en el ciclo de vida del desarrollo el software.

Y para finalizar, deciros, que hay varias herramientas por ahí, aunque yo la verdad, solo he usado la que viene con Visual Studio 2008.

Para activar el Code Coverage, únicamente tenéis que ir a:

Test -> Edit Test Run Configuration -> Local Test Run

Y en el dialogo que aparece, vamos a la pestaña de Code Coverage y elegimos los proyectos a los que se lo queremos aplicar.

Aqui teneis una captura del Code Coverage de uno de los proyectos que hemos acabado recientemente, aunque no se vea el porcentaje total (por no desvelar el proyecto que es), ha sido un 91%.

Code Coverage en el ultimo proyecto en el que he estado

Code Coverage en el ultimo proyecto en el que he estado

Nada más por hoy mis druguitos. Os dejo que tengo que estudiar, pero no os quedais solos, aqui teneis a The Pains of Being Pure At Heart que son geniales y me ponen mogollon.

Ejemplo práctico: Creando Unit Test para probar nuestro código

Por norma general los desarrolladores (y por supuesto los testers 😉 ) ocupan mucho tiempo de su jornada para probar el código y asegurarse que la funcionalidad esta implementada correctamente y cumple con la finalidad para la que haya sido diseñada la aplicación.

TDD

Tdd, es la abreviatura de Test Driven Development (Desarrollo Orientado a Pruebas) y es una metodología donde se contempla el ciclo de vida del desarrollo de software de la siguiente forma (y orden):

  • Creación de la pruebas unitarias o unit testing
  • Implementación del código que está probando la prueba
  • Refactoring del código anteriormente implementado

Para que esta metodología funcione, el código tiene que estar lo suficiente estructurado como para poder crear unit test que prueben pequeñas partes de la funcionalidad. Sigue leyendo