Lectura 04: Introducción a NUnit

1. Que son y para que sirven los tests NUnit

 Los Tests NUnit son test de "calidad de las clases", es decir, con un test NUnit lo
que hacemos es comprobar si una clase funciona exactamente como debería.
 La importancia de estos tests radica en que es la forma mas completa y ordenada de
comprobar que dichas clases están libres de fallos.

2. Que tengo que hacer para escribir tests NUnit?

 Aprender la sintaxis de C#
 Mirar las clases que tienen ya un test NUnit, elegir uno y leerlo para ver mas o
menos como esta escrito.
 Elegir una clase por la que se tenga interés y no tenga ya un test NUnit.
 Leerse la guía de estilo de tests NUnit.

3. Pasos a Seguir
 Si nunca has escrito un test NUnit puedes conseguir una plantilla para empezar. El
fichero se puede conseguir desde el CVS de mono y es:
mcs/class/doc/TemplateTest.cs
 Copia esta plantilla en otro fichero y empieza a modificar, en esa plantilla, tienes
unas marcas "[algo que poner]" que indican que debes poner en cada uno, ve
rellenándolos con el código apropiado, la plantilla esta llena de comentarios para
darte pistas sobre como debes seguir, también es buena idea ver otros tests para ver
ejemplos reales de tests. En
mcs/class/corlib/Test/System.Collections/CollectionBaseTest.cs tienes un test
cortito.
 El directorio que contendrá el fichero que depende del "assembly"/espacio de
nombres de la clase dependerá sobre que estés creando el test. En mcs/class hay un
directorio para cada "assemby". En cada "assembly" hay un directorio Test, por
ejemplo dentro de mcs/class/corlib/Test. In el directorio test donde estemos, hay
subdirectorios con cada espacio de nombres en el "assembly", por ejemplo
mcs/class/corlib/Test/Sytem., Pon tu nuevo test en el subdirecorio apropiado.
 Una vez que la clase test este completa, debes añadirla al fichero "AllTests.cs" en el
mismo directorio que tu nuevo test, Añade una llamada a "suite.AddTest()" pasando
el nombre de tu nuevo test como parámetro. Allí hay bastantes ejemplos de como
hacerlo.
 Una vez todo esto este hecho, puedes hacer un "make test" desde el directorio raíz
de mcs. Tu test de clase será incluido automáticamente en la construcción junto con
el resto de los tests.

4. Consejos para escribir tests NUnit

4.1. Pon un mensaje único a cada assert

Interbank Instructor: MCT Luis Dueñas

 Lectura 04: Introducción a NUnit

Es mejor usar una cadena única para cada Assert(), para que así sea fácil localizar donde
ha fallado el test. De otra forma seria difícil saber donde ha fallado el test
Mal:
AssertEquals("array match", compare[0], i1[0]);
AssertEquals("array match", compare[1], i1[1]);
AssertEquals("array match", compare[2], i1[2]);
AssertEquals("array match", compare[3], i1[3]);
Bien:
AssertEquals("#A01", compare[0], i1[0]);
AssertEquals("#A02", compare[1], i1[1]);
AssertEquals("#A03", compare[2], i1[2]);
AssertEquals("#A04", compare[3], i1[3]);
Una vez hayas usado un numero en un Assert(), no lo cambies luego, la gente puede
usarlos para identificar errores.

4.2. Use AssertEquals() para comparar valores, nunca Assert()

Nunca compare dos valores con Assert(), si el test falla, la gente no podrá saber que fue
mal, mientras que si usa AssertEquals(), el propio método dirá que valor se esperaba.
Mal:
Assert ("A01", myTicks[0] == t1.Ticks);
Bien:
AssertEquals ("A01", myTicks[0], t1.Ticks);

4.3. Constructores
Cuando escribas el Test, asegúrate que un constructor no toma ningún argumento.
public class DateTimeTest : TestCase
{
public DateTimeTest() : base ("[MonoTests.System.DateTimeTest]") {}
public DateTimeTest (string name): base(name) {}

public static ITest Suite

{
get {
TestSuite suite = new TestSuite ();
return suite;
}

Interbank Instructor: MCT Luis Dueñas

 Lectura 04: Introducción a NUnit

}
}

4.4. Espacios de Nombres

Mantén el espacio de nombres de cada directorio de tests consistente, todos los tests que
están referenciados en el mismo AllTests.cs deben estar en el mismo espacio de
nombres. Por supuesto puedes usar sub-espacios de nombres como quieras, sobre todo
para subdirectorios de tu test.
Por ejemplo, si tu AllTests.cs esta en el espacio de nombres "MonoTests" y tienes un
subdirectorio llamado System, puedes poner todos los tests de ese directorio en el
espacio de nombres "MonoTests.System".

4.5. Prueba tus tests con el Runtime de Microsoft

Si es posible, intenta probar tus conjuntos de tests con el Framework de Microsoft en
Windows y asegúrate de que todos los tests son correctos, es decir el Runtime de
Microsoft debe "aprobar" todos los tests.
No te preocupes si no tienes un Windows a tu disposición, otras personas podrán probar
tus tests en Windows.
A veces puedes descubrir que un test no se ejecuta como debería en el SDK de
Microsoft, puede ser por varias razones, entre ellas que haya un error en su entorno, o
que algo esta mal o es ambiguo en su documentación, en este caso, por favor, ponga una
descripción detallada del problema en mcs/class/doc/API-notes (CVS de mono) o pídale
a alguien que tenga acceso a el que lo ponga. Y también mándelo a la lista de correo
(tanto a la de mono como a la de mono-hispano). Mono mandara eso a la gente de
Microsoft de vez en cuando, para ayudarles a corregir su documentación y su Runtime.

4.6. El lenguaje perfecto para escribir tests es el ingles

Como el lenguaje común mas hablado en el proyecto es el ingles, mas que nada por ser
prácticos, seria recomendable hacer los tests (los mensajes) en ingles, si no sabes ingles,
no te preocupes, siempre habrá alguien que lo traduzca

Interbank Instructor: MCT Luis Dueñas

 Lectura 04: Introducción a NUnit

Usando NUnit
Pruebas al Código en .NET
Hoy en día las unidades de prueba (unit testing) se han convertido en una poderosa
herramienta de pruebas al código, ganando popularidad día con día, sobre todo en las
empresas dónde los proyectos de software comúnmente alcanzan varios niveles de
complejidad. Unit Testing, es una de la más importantes prácticas de la metodología
de programación XP (eXtreme Programming).

Sobre Unit Testing

Cuando escribimos código no lo hacemos de forma perfecta desde la primera vez, la
compilación misma del proyecto es la primer prueba a nuestra aplicación. El compilador
verifica la sintaxis e indica las líneas dónde ha encontrado errores. Es una gran ayuda
pero termina ahí. El programa puede y ciertamente contendrá errores, muchos de los
cuáles son visibles sólo hasta el tiempo de ejecución de la misma. Tenemos entonces
que regresar al código, buscar la línea del error y corregirlo, algo que aumenta los
tiempos de desarrollo. No podemos eliminar todos los errores, pero sí es posible
reducirlos a un nivel más aceptable.
Aquí es dónde entran las Unit Testing. Ayudándonos a buscar errores escribiendo
pruebas. Estas pruebas son programas, métodos actualmente. Ellos prueban cada parte
del proyecto y verifican si están trabajando correctamente.
Algunas veces no deseamos escribir pruebas, sobre todo al principio, pensamos que
escribirlas es redundante, para que hacerlo sí el código funciona bien, el problema es
que no siempre es así. Aun escribiendo las clases más sencillas estas son propensas a
errores.
Es verdad que en términos de escribir código es más el tiempo que se consume al
escribir código y pruebas que sólo código, pero hacerlo tiene sus remuneraciones. No
escribir pruebas es más rápido sólo cuándo se hace sin errores.
Unit Testing es una práctica muy importante sobre todo en el mundo empresarial, dónde
los resultados esperados son bastante complejos. El dejar muchos errores en las
aplicaciones finales conlleva desarrollos más lentos lo que evidentemente no son nada
favorables para las empresas.
Existen muchas otras herramientas de pruebas al código además de la mencionada
NUnit. Existen para los más variados lenguajes tales como: JUnit para Java, PUnit para
Phyton, DUnit para Delphi, etc.

Un poco más...
Si ponemos como ejemplo una clase llamada Cálculos, dónde uno de los métodos se
encarga de dividir dos números y devolver el resultado. El conjunto de pruebas deberá
consistir en muchas operaciones simulando los casos más excepcionales, como la
división sobre 0.
Estas pruebas de realizarse de forma tradicional, esto es ejecutando la aplicación,
cuando el proyecto es considerablemente extenso podrá tomar bastante tiempo el
realizarlas; o bien, con un solo click, usando las unidades de prueba. Ejecutándose

Interbank Instructor: MCT Luis Dueñas

 Lectura 04: Introducción a NUnit

automáticamente todo el conjunto de pruebas y devolviendo los resultados de las

pruebas en simples true o false, sí estas se han pasado o no.

Sobre Nunit
Inicialmente portada de JUnit (Java Unit, unidad de pruebas para clases en Java), esta
herramienta de pruebas para .NET se encuentra en su segunda revisión mayor, la
versión 2. Enteramente escrita en C#, ha sido rediseñada para tomar ventaja de muchas
de las características de los lenguajes .NET, por ejemplo atributos personalizados y
otras capacidades relacionadas con la reflexión. Hay que resaltar que esta utilidad es de
distribución libre, en la página del proyecto (http://nunit.sourceforge.net) puedes
encontrar el código fuente de esta gran herramienta.

Una sencilla prueba

Vamos a ejemplificar de manera general cómo se realizan las pruebas, ayudándonos
para ello de una clásica clase "Cuenta". Antes de comenzar con el código:
Debes conseguir la última versión de NUnit (yo tengo la 2.1.4), puedes bajarla
completamente gratis de www.nunit.org.
Instala los ensamblados. Automáticamente se instalan las dll´s necesarias así como la
interfaz gráfica.
Crea un nuevo proyecto de biblioteca de clases. Nómbralo Banco o cómo desees.
Agrega una referencia al ensamblado nunit.framework.
El ensamblado nunit.framework contiene el espacio de nombres NUnit.Framework, el
cuál contiene los métodos estáticos (shared en visual basic .Net) que usaremos para
conocer el comportamiento de los métodos de la clase cuenta.
El código de la clase cuenta:
using System;
namespace Banco
{
public class Cuenta
{
private float balance;
public Cuenta(){}
public void Deposito(float Cantidad)
{
balance += Cantidad;
}
public void Retiro(float Cantidad)
{
balance -= Cantidad;

Interbank Instructor: MCT Luis Dueñas

 Lectura 04: Introducción a NUnit

}
public void Transferencia(Cuenta Destino, float Cantidad)
{
}
public float Balance
{
get
{
return balance;
}
}
}
}
El código de la clase CuentaTest:
//Importamos los espacios de nombres
using System;
using NUnit.Framework;
namespace Banco
{
[TestFixture] // Establecemos el atributo que índica la clase que contiene las pruebas.
public class CuentaTest
{
public CuentaTest(){}
[Test] //Especificamos cuál es el método de prueba.
public void Transferencias()
{
//creamos la cuenta origen con un saldo de 200.00
Cuenta origen = new Cuenta();
origen.Deposito(200.00F);
//creamos la cuenta destino con un saldo de 150.00
Cuenta destino = new Cuenta();
destino.Deposito(150.00F);
//transferimos 100.00 de la cuenta origen a la destino
origen.Transferencia(destino, 100.00F);
//sí todo ha salido bien, debemos tener

Interbank Instructor: MCT Luis Dueñas

 Lectura 04: Introducción a NUnit

//un balance de 250.00 en la cuenta destino

//y de 100.00 en la origen
Assert.AreEqual(250.00F, destino.Balance);
Assert.AreEqual(100.00F, origen.Balance);
}
}
}

Antes de continuar hay que mencionar que el atributo [Test] es el que indica a NUnit
qué método está marcado para prueba dentro de la clase que ha sido establecida con
[TestFixture]. Este método debe respetar una cierta signatura.
public void MethodName()
El Método estático AreEqual de la clase Assert, compara dos tipos, si no son iguales
genera una Exception del tipo AssertException. Este método tiene varias sobrecargas
que facilitan este tipo de comparaciones.
Ahora:
 Compilamos la librería
 Abrimos la interfaz gráfica de NUnit (usualmente ubicada en menú programas).
 Cargamos el ensamblado (Menú File > Open) Imagen.
 Presionamos el botón Run, para comenzar las pruebas. Imagen.
Obtenemos una barra de color rojo, con varios mensajes de error. Todo normal, ya que
el método de prueba que hemos escrito contiene dos líneas que verifican que los valores
obtenidos dentro de las operaciones sean los que se esperan.
Assert.AreEqual(250.00F, destino.Balance);
Assert.AreEqual(100.00F, origen.Balance);
Y al no contar con código dentro del método de "Transferencia" los valores nunca se
equilibran al realizar las operaciones.
Ahora, sin cerrar la ventana de la GUI de NUnit, modificamos el método de
"Transferecia" con:
public void Transferencia(Cuenta Destino, float Cantidad)
{ Destino.Deposito(Cantidad);
Retiro(Cantidad); }
 Recompilamos la librería.
 Automáticamente se recarga el ensamblado en el GUI de NUnit.
 Volvemos a correr las pruebas.
 Ahora, al realizar todas la operaciones correctamente, obtenemos una barra verde
sin ningún mensaje de error. Imagen.

Interbank Instructor: MCT Luis Dueñas