Atributos de NUnit 2.x

A la espera de las novedades que introducirá el lanzamiento de NUnit 3.0, vamos a presentar el uso de este unit-testing framework en la versión 2.4.x del mismo.

NUnit se presenta como una herramienta muy útil dentro del marco del desarrollo orientado a pruebas (TDD), permitiéndonos realizar las pruebas unitarias de forma automatizada y cubriendo todos los casos de uso que deban implementar las clases de nuestra aplicación. En el TDD, el flujo normal de desarrollo consiste en la escritura de las pruebas, escribir el código que debe pasarlas y hacer un refactoring para eliminar código duplicado. La escritura de las pruebas y la ejecución de los métodos que deben pasarlas correrá a cargo de NUnit.

El uso de NUnit se basa en el uso de atributos personalizados, que indicarán al framework de NUnit qué clases y qué métodos son los de pruebas, y qué pruebas deben realizarse sobre el código. Los atributos de NUnit en su versión 1.x eran nombrados según las convenciones del .Net Framework, pero esto cambió en la 2.x, usando ahora los atributos personalizados que pasamos a enumerar.

Atributos cuyo ámbito de uso es a nivel de clase:

• TestFixture: Se usa para indicar que una determinada clase contiene métodos de prueba. Entre las restricciones para la clase están que deberá contar con un constructor por defecto (siendo válido el que proporciona automáticamente .Net) y que debe ser pública para que NUnit pueda acceder a ella para la ejecución de las pruebas.

Atributos cuyo ámbito de uso es a nivel de método:

• Test: Su uso es indicar que un determinado método es un método de prueba. Entre las restricciones para el método de prueba estarán que no devuelva ningún valor (void) y no reciba parámetros, y que la clase a la que pertenezca esté marcada con el atributo TestFixture.

• ExpectedException: Indica que el método va a producir una excepción del tipo indicado en el atributo (exactamente ese tipo, no otro distinto, aunque herede del mismo). La prueba se considera superada si al ejecutarlo lanza la excepción esperada.

• TestFixtureSetUp: Inicializa el entorno de pruebas antes de ejecutarlas, es decir, establece las condiciones necesarias para que las pruebas se realicen en un ambiente idóneo. Se ejecutará antes que cualquier otro método. Sólo puede haber un método marcado con el atributo TestFixtureSetUp dentro de una clase TestFixture.

• TestFixtureTearDown: Se encarga de restaurar el entorno creado para las pruebas por el método marcado con TestFixtureSetUp. Sólo puede haber un método marcado con este atributo dentro de la clase.

• Setup: Inicializa y establece el entorno antes de la ejecución de cada prueba, es decir, justo antes de cada método de prueba que se ejecute. Generalmente se encarga de inicializar variables y dejar el entorno “limpio” para la ejecución de la prueba. Sólo puede haber un método marcado como Setup dentro de cada clase de pruebas.

• TearDown: Su función es restaurar el entorno tras la ejecución de cada prueba unitaria. Sólo puede haber un método marcado como TearDown dentro de cada clase de pruebas.

El plan de ejecución de las pruebas será, por tanto, el siguiente:

A nivel de método y clase tenemos los siguientes atributos:

• Category: Otra opción que tenemos es agrupar las pruebas según categorías, de modo que podamos realizar la ejecución de un determinado bloque de pruebas simplemente indicando la categoría a la que pertenece la prueba. Para ello haremos uso del atributo Category, que puede usarse de forma conjunta a los atributos TestFixture o Test, es decir, a nivel de clase o de método.

• Explicit: Obliga a indicar durante el proceso de pruebas que se incluya una determinada prueba en el mismo. Es decir, hay que indicar explícitamente que deseamos ejecutar una determinada prueba, siendo ignorada por NUnit en caso contrario.

• Ignore: Es usado para ignorar una determinada prueba y no incluirla en el plan de pruebas. Al ejecutar NUnit, se marcará con amarillo, indicando que hay código sin probar. La ventaja de esto es que el código estará incluido en el ensamblado, ya que es compilado, pero lo excluimos de las pruebas igual que si todo el código del método o la clase hubiese sido comentado.

En la próxima entrega veremos un ejemplo de clase de pruebas haciendo uso de estos atributos y de otra de las características de NUnit, las aserciones (Asserts), que nos permitirán validar si el resultado esperado en las pruebas coincide con el que nos devuelve nuestro método probado.

Actualización (8 de abril de 2008): 

El blog registra una nueva entrada el 3 de abril de 2008 sobre Cheat Sheets, en concreto recogiendo una "hoja de trucos" o guía de Test-Driven Development, disponible para su descarga en formato PDF.