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 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;
        }

        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
			//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.

Para terminar

    Este ha sido un ejemplo muy sencillo, y los conjuntos de pruebas pueden ser tan extensos como se requieran.

    Debido a que las posibilidades de uso son bastante extensas no es posible abarcar todas ellas aqu�. Sin embargo, espero que este ejemplo ayude a aclarar un poco el uso de esta herramienta. En la gu�a de inicio r�pido que se descarga con NUnit, se habla con mayor profundidad de la mayor�a de estas opciones.

    Para mayor informaci�n sobre NUnit, adem�s de la gu�a de inicio r�pido que se mencion�, tenemos la documentaci�n que se presenta en la p�gina del proyecto.

Saludos...

Fichero con el c�digo de ejemplo

• Banco_C# - 6 KB.
• Banco_VB - 5 KB.