PDF de programación - TDD: Sharepoint WebParts con Unit Testing

Títul
o

Text
o

TDD: Sharepoint WebParts con Unit Testing

Este mes quería seguir hablando de Microsoft Azure y las
capacidades que ofrece como plataforma de desarrollo de soluciones
software creadas mediante “servicios en la nube”, pero como hasta
hoy mismo no he recibido la invitación del equipo de desarrollo de
Microsoft Azure para poder desplegar servicios en su plataforma,
tendré que dejar esto para otro artículo posterior.

A cambio, este mes me voy a centrar en las buenas prácticas en
desarrollo, y en concreto en las que afectar al desarrollo de WebParts
para Microsoft Sharepoint, la plataforma de portal web y gestión
documental de más éxito en este momento.

Para desarrollar nuestra pequeña prueba de Test Unitario en
desarrollos de Webparts de Sharepoint, vamos a emplear estos
componentes:

- Windows SharePoint Services 3.0 o Microsoft Office SharePoint

Server 2007

- Windows Server 2008 como S.O. del servidor
- VisualStudio 2008 como herramienta de desarrollo
- NUnit como framework para el test unitario
- Y por último TestDriven.NET para lanzar los Tests de manera

sencilla desde VS2008

¿Qué es lo que tenemos que hacer? Vamos a definirlo con una
definición de requerimientos “habitual”: Lo que vamos a hacer es
desarrollar un WebPart muy sencillo que mostrará un mensaje de
bienvenida a nuestros usuarios en la página de SharePoint donde lo
mostremos. Este mensaje variará según la hora de nuestro servidor,
y además será configurable. Y eso es todo lo que sabemos, ¡manos a
la obra!

Testeo Unitario de un Web Part

Vamos a limitar nuestra aproximación al Test Driven Development
(TDD) a su forma más básica:

1. Escribir un test que falle
2. Corregirlo para que funcione
3. Repetir

Si seguimos esta estructura, nuestro programa se irá completando a
medida que vayamos añadiendo nuevos “fallos” a nuestro programa
y solucionándolos. Para hacer esto vamos a ir por pasos.

Paso 1: Proyecto de Test

Empezamos por crear el proyecto de test en VS2008, que definimos
como una Biblioteca de clases C# que denominamos
TestUnitarioSimple.Test a la que añadimos una referencia al

framework de NUnit mediante el componente .NET “nunit.framework”
y también añadimos un referencia a “nunit.framework.extensions”
para disponer de las extensiones del GUI de NUnit en VisualStudio.

Renombramos el nombre de clase para que sea el mismo que la clase
que vamos a testear, en nuestro caso “Saludo”, lo que hacemos
renombrando el fichero para que VS2008 se ocupe de actualizar
todas las referencias necesarias.

Modificamos el código añadiendo el “using” de nunit.framework,
declarando el [Test Fixture] para identificar esta clase como
contendora de Tests, y declaramos nuestro primer [Test]. Para darle
un nombre, voy a seguir la nomenclatura
“Metodo_Escenario_Comportamiento”, para que sea más fácil hacer

un seguimiento posteriormente de tests que fallen.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NUnit.Framework;

namespace TestUnitarioSimple.Test
{
[TestFixture]
public class Saludo
{
[Test]
public void RecuperaMensaje_ParametroValido_DevuelveMensaje()
{
}
}
}

Este código lo podemos testear ya desde VS2008, pulsando con el
botón derechodel ratón en el nombre del proyecto y seleccionando
“Run Tests” (si hemos instalado TestDriven.NET). El resultado es
correcto, ya que aún no le hemos hecho fallar.

1 passed, 0 failed, 0 skipped, took 11,64 seconds (NUnit 2.4).

Paso 2: Clase “Saludo”

Ahora añadimos a la solución un nuevo proyecto de tipo Clase C#
que llamamos “TestUnitarioSimple”, donde residirá el código que
tendrá la funcionalidad de nuestro WebPart. Una vez creado,
nuevamente renombramos el archivo de clase a “Saludo.cs” y
permitimos a VS2008 que se ocupe de las referencias.

Añadimos un método público llamado RecuperaMensaje con un
parámetro de tipo String, de acuerdo a lo que hemos definido para
nuestro Test.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace TestUnitarioSimple
{
public class Saludo
{
public string RecuperaMensaje(string mensaje)
{
throw new Exception("Sin implementar");
}
}
}

Paso 3: Fallamos el Test

Ahora es el momento de hacer que el test falle, verificando que
nuestro código “RecuperaMensaje” no está implementado
debidamente. Para eso primero añadimos la referencia de
TestUnitarioSimple a TestUnitarioSimple.Test, de manera que
podamos invocar la clase TestUnitarioSimple desde nuestro Test. A
continuación definimos un test simple que valide si es igual el
mensaje devuelto por nuestro método Saludo a nuestro mensaje con
un saludo.

public void RecuperaMensaje_ParametroValido_DevuelveMensaje()
{
TestUnitarioSimple.Saludo hola = new TestUnitarioSimple.Saludo();
string mensaje = "Bienvenido al mundo SharePoint";

Assert.AreEqual("Buenas tardes, " + mensaje,
hola.RecuperaMensaje(mensaje));
}

Si testeamos esto veremos un mensaje de Error, como debemos
esperar:

Error 1 TestCase
'TestUnitarioSimple.Test.Saludo.RecuperaMensaje_ParametroValido_Devu
elveMensaje'
failed: System.Exception : Sin implementar
en TestUnitarioSimple.Saludo.RecuperaMensaje(String mensaje) en
C:\Users\Raffloyol\Documents\Visual Studio
2008\Projects\TestUnitarioSimple.Test\TestUnitarioSimple\Saludo.cs:lín
ea 12
en
TestUnitarioSimple.Test.Saludo.RecuperaMensaje_ParametroValido_Devue
lveMensaje() en C:\Users\Raffloyol\Documents\Visual Studio
2008\Projects\TestUnitarioSimple.Test\TestUnitarioSimple.Test\Saludo.c
s:línea 18 C:\Users\Raffloyol\Documents\Visual Studio
2008\Projects\TestUnitarioSimple.Test\TestUnitarioSimple\Saludo.cs
12

La ventana de NUnit, desde la que también podemos lanzar los tests,
nos muestra exactamente el error y dónde se ha producido.

Paso 4. Solucionamos el test fallido

A continuación hemos de emprender el siguiente paso del TDD,
escribir el código que pase el test. Vamos a ir paso a paso, de
manera que por ahora solucionaremos el test de la manera más
simple posible.

Modificamos el código de nuestra clase Saludo, para que devuelva el
mensaje que requerimos:

public string RecuperaMensaje(string mensaje)
{
//throw new Exception("Sin implementar");
return "Buenas tardes, Bienvenido al mundo SharePoint";
}

Si ahora corremos nuestros Test, vemos que todo está OK.

Lo importante aquí es darse cuenta de que este estado verde no
significa que nuestro código esté bien. Simplemente estamos
desarrollando nuestros pasos hasta que el código haga lo que
queremos que haga de una manera completamente correcta (lo que
nos garantiza el TDD), algo de lo que todavía estamos muy lejos. Por
ahora sólo sabemos que tenemos una función que toma un string
como parámetro y devuelve otro, no mucho más.

Paso 5: Añade más Tests, repáralos y repite

Vamos a iterar en nuestro proceso, añadimos otro Test a nuestro
TestFixture, en este caso vamos a testear contra otro mensaje:

[Test]
public void
RecuperaMensaje_ParametroAlternativoValido_DevuelveMensaje()
{
TestUnitarioSimple.Saludo hola = new TestUnitarioSimple.Saludo();
string mensaje = "Bienvenido a nuestro sitio TDD";
Assert.AreEqual("Buenas tardes, " + mensaje,

hola.RecuperaMensaje(mensaje));
}

Si ejecutamos los tests, vemos que el mensaje de error nos indica
claramente que el mensaje esperado y el devuelto no coinciden:

TestUnitarioSimple.Test.Saludo.RecuperaMensaje_ParametroAlternativoV
alido_DevuelveMensaje:
String lengths are both 45. Strings differ at index 27.
Expected: "Buenas tardes, Bienvenido a nuestro sitio TDD"
But was: "Buenas tardes, Bienvenido al mundo SharePoint"
--------------------------------------^

Lo podemos arreglar fácilmente, si cambiamos el código de nuestra
función RecuperaMensaje:

public string RecuperaMensaje(string mensaje)
{
//throw new Exception("Sin implementar");
//return "Buenas tardes, Bienvenido al mundo SharePoint";
return "Buenas tardes, " + mensaje;
}

Este código vemos que además de resolver este test, no afecta al
anterior. ESTA ES LA BASE DEL TDD:

- No añadimos código extra no necesario
- La resolución de un Test no implica fallar los anteriores

Paso 6: Test de nuevas características

Vamos a seguir complicando el desarrollo. Según nuestros
requerimientos, hemos de tener en cuenta también la hora del día
para devolver el mensaje más adecuado. Para evitarnos retrasos en
el testeo no basaremos nuestra función para devolver la hora en la
hora del sistema, porque vamos a necesitar ejecutar nuestros tests
por la mañana, tarde y noche, así que lo que debemos hacer es crear
un método que acepte una hora y devuelva un mensaje apropiado.

El código que añadimos en los ficheros .cs es este:

[Test]
public void
RecuperaSaludoSegunHora_Mañana_RecuperaSaludoMañana()
{
TestUnitarioSimple.Saludo hola = new TestUnitarioSimple.Saludo();
TimeSpan timeSpan = new TimeSpan(5,0,0);
Assert.AreEqual("Buenos días",
hola.RecuperaSaludoSegunHora(timeSpan));
public string RecuperaSaludoSegunHora(TimeSpan timeSpan)
{
throw new Exception("Sin implementar");
}

El resultado es el que debemos esperar: dos tests pasan y uno falla.
Al menos podemos estar seguros de que lo que hemos hecho no ha
afectado a lo anterior, la gran ventaja de TDD.

Nuevamente, ahora se trata de escribir