Burbujas en .NET : TDD

[ALM 09] Material de las sesiones: Surface y TDD

Eduard Tomàs i Avellana — Thu, 26 Nov 2009 13:56:06 GMT

Hola a todos! Finalmente tuve el placer de dar no una, sino dos sesiones en las ALM Sessions 09. No era la idea inicial, pero mi compañero Juan Carlos finalmente no pudo dar la de Surface, así que la di yo (y es que por suerte o por desgracia me encanta hablar).

La primera sesión fue precisamente la de Surface, en el track de Diseño y UX. La intención inicial era haber traído la surface que tenemos en raona, pero por temas logísticos fue imposible… Así que tuve que dar una presentación sobre Surface sin Surface que es como una noche de fiesta sin lig… esto, que le falta algo, vamos. Intenté explicar un poco que es la Surface, y el cambio de paradigma que supone desarrollar para ella. Mostré el emulador que viene con el SDK de Surface (que os animo a todos a probar) y vimos algunos de los controles de dicho SDK. Finalmente exploramos el futuro que nos espera con WPF 4 unificando la programación multi-touch en Surface y en Windows 7.

La segunda sesión, en el track de arquitectura, versó sobre TDD. Intenté explicar que es TDD, pero sobre todo por que usar TDD sin entrar en detalles sobre el como hacer pruebas unitarias (lo que daria para varias sesiones). Luego mencioné los pequeños cambios que trae VS2010 para hacernos llevadera la tarea de realizar TDD (recordad las sabias palabràs del Capità Enciam: los pequeños cambios son poderosos) y empecé a desarrollar una clase usando TDD, intentando hacer énfasis en los pensamientos que uno tiene gracias a usar TDD. Me quedé un poco corto de tiempo y tambien me comentaron que la combinación de colores que tengo en mi VS2010 será muy cómoda para programar pero muy mala para proyectar… Disculpas por si no pudisteis ver bien el código por culpa de los colores :(

En fin, que más puedo deciros: yo me lo pasé en grande durante todo el evento: dando sesiones, escuchándolas, hablando y conociendo a gente… ah si! y también comiendo y bebiendo jejejee… :)

Os dejo las presentaciones de ambas sesiones.

Un saludo y nos vemos en la próxima movida!!! ;)

ALM Sessions’09 – Test Driven Development

Eduard Tomàs i Avellana — Tue, 17 Nov 2009 17:00:19 GMT

Hola a todos!! Este año tengo el placer de realizar una presentación en las ALM Sessions’09.

En concreto hablaré sobre Test Driven Development: que és, como su uso junto con otras buenas prácticas de desarrollo puede ayudarnos a ganar en calidad y como podemos implantarlo en un equipo de desarrollo.

También veremos que herramientas trae Visual Studio 2010 y como nos pueden ayudar a realizar de forma más sencilla TDD.

Os recomiendo que los que podais os paseis por Madrid este 24 de Noviembre, porque vale la pena. Si el año pasado las sesiones fueron buenas este año todavía más porque hay hasta 6 tracks simultáneos: Procesos, Calidad y testing, Herramientas, Arquitectura, Diseño/UX y Plataforma de aplicaciones. Si veis la agenda observaréis la gran cantidad de temas que se tratan. Es casi imposible no encontrar ninguno de vuestro interés!

Un saludo y nos vemos por allí!!!

Pexcando errores en nuestro código…

Eduard Tomàs i Avellana — Mon, 04 May 2009 09:03:00 GMT

Buenas… ¿Conoceis Pex? Es una herramienta que genera tests unitarios a partir de nuestro código. Su característica principal es que analiza el código e intenta generar tests unitarios que cubran todas las posibilidades de nuestro código.

Vamos a ver un pequeño ejemplo de como usarlo y como se integra con Microsoft Code Contracts. Antes que nada os recomiendo echar un vistazo al genial Post de Jorge Serrano Precondiciones y Microsoft Code Contracts v1.0.

Vamos a hacer un método muy simple (y conocido por aquellos que desarrollen en VB.NET):

 public static class StringExtensions
{
     public static string Right(this string value, int chars)
     {
         return value;
     }
}

El método Right debe devolver los últimos chars carácteres de la cadena value.

Simplemente con este código nos descargamos Pex y lo instalamos. Una vez hecho vereis que nos aparece una nueva opción el menú contextual del “Solution Explorer” llamada “Run Pex Explorations”. Con esta opción lo que hacemos es que Pex analice todo nuestro código buscando generar Tests unitarios para nuestros métodos públicos:

Si ejecutamos esta opción Pex analiza el código y nos genera tests unitarios para el método Right:

En este caso nos ha generado un solo test. Es importante saber como Pex genera los tests: no lo hace al azar, sinó que intenta cubrir el máximo de nuestro código. En nuestro caso como no nuestro código apenas hace nada, con un solo test, Pex obtiene una cobertura del 100% y se queda ahí. Evidentemente Pex nada sabe de cual debe ser el resultado de nuestro método, por lo que no puede generar tests unitarios funcionales.

Ahora antes de empezar a analizar código vamos a ver el uso de Code Contracts. Una vez instalada, añadís la referencia a “Microsoft Contracts Library” (Microsoft.Contracts.dll). En el framework 4.0 parece ser que se incluirá el código dentro de mscorlib, por lo que no será necesario usar referencia alguna.

Ya estamos listos para definir los contratos en nuestra clase. Para ello debemos especificar las precondiciones de nuestro método. Una precondición es algo que debe cumplirse sí o sí para asegurar que la llamada anuestro método es “válida”.

Una precondición de nuestro método es que NO vamos a aceptar que la cadena de entrada sea nula. El método Contract.Requires sirve para especificar las precondiciones:

public static string Right(this string value, int chars)
{
    Contract.Requires(value !=null);
    return value;
}

Si lanzamos Pex ahora vemos que… no ocurre nada distinto. Esto es porque por defecto los contratos no se evalúan. Si queremos que se evalúen debemos irnos a la pestaña “Code Contracts” de las propiedades del proyecto y habilitar “Perform runtime contract checking”. Una vez hecho esto, volvemos a ejecutar Pex y obtenemos lo siguiente:

Vemos que ahora Pex nos ha generado dos tests: uno que pase el contrato (le manda una cadena con un ‘\0’ y otro que no (le manda null).

Otra pecondición que vamos a usar es que el segundo parámetro debe ser mayor que cero:

public static string Right(this string value, int chars)
{
    Contract.Requires(value !=null);
    Contract.Requires(chars > 0);
    return value;
}

Una vez establecidas las precondiciones nos interesa establecer las postcondiciones, es decir todo aquello que aseguramos que se cumple al finalizar el método. Para ello usamos Contract.Ensures. P.ej. para añadir una postcondición que asegure que nunca devolveremos null:

public static string Right(this string value, int chars)
{
    Contract.Requires(value !=null);
    Contract.Requires(chars > 0);
    Contract.Ensures(Contract.Result<string>() != null);
    return value;
}

Una cosa realmente importante: Contract.Ensures se evalúa SIEMPRE al final del método… aunque como en este caso lo hayamos colocada antes del return, se evaluará después del return. El secreto está en que Code Contracts viene con un MSIL rewriter que modifica el código MSIL desplazando las llamadas a Contract.Requires al principio del método y de Contract.Ensures al final. El método Contract.Result<T> sirve para acceder al valor retornado por el método.

Contract.Requires no deja obsoleto a Debug.Assert. Ambos son necesarios: Con Contract.Requires comprobaremos las precondiciones lógicas de nuestro método, mientras que Debug.Assert lo seguiremos usando para comprobaciones de depuración (comprobaciones internas).

Tenemos el contrato de nuestro método especificado, tenemos a Pex para que nos genere tests unitarios… podemos empezar a meter código!

 public static class StringExtensions
{
     public static string Right(this string value, int chars)
     {
         Contract.Requires(value !=null);
         Contract.Requires(chars > 0);
         Contract.Ensures(Contract.Result<string>() != null);
         if (chars >= value.Length) return value;
         else
         {
             int inicial = value.Length - chars;
             if (inicial < 0) inicial = 0;
             return value.Substring(inicial, chars);
         }
     }
}

Una vez tenemos el código ya listo (o eso creemos jejejeeee…) relanzamos Pex para que nos cree un nuevo conjunto de tests unitarios para nuestro método. Como ahora tenemos un código un poco más complejo, Pex nos creará varios tests unitarios:

Pex ha creado 4 tests unitarios con el objetivo de cubrir al máximo nuestro código. A partir de este punto si queremos podemos generar un proyecto de test con estos 4 tests unitarios. Los podemos seleccionar desde la ventana de Pex Exploration Results y le dais a “Save”:

Con ello Pex nos genera el proyecto de tests unitarios:

El proyecto tiene dos archivos especiales: El fichero StringExtensionsTest.cs y el fichero StringExtensionsTest.Right.g.cs.

El segundo (.g.cs) se regenera cada vez que ejecutamos Pex, por lo que NO debemos poner código en él. El primero por su parte se mantiene y contiene lo que Pex llama PUTs, o Parametrized Unit Tests. Un PUT es un test unitario pero que acepta parámetros. Pex los usa para poder “agrupar” clausulas Assert: En lugar de colocar un Assert para cada test unitario, coloca uno de solo en el PUT y los tests unitarios que genera Pex, son llamadas al PUT con los parámetros correspondientes.

P.ej. el código del PUT generado es:

[PexMethod]
public string Right(string value, int chars)
{
    // TODO: add assertions to method StringExtensionsTest.Right(String, Int32)
    string result = StringExtensions.Right(value, chars);
    return result;
}

Como se puede ver no hace nada salvo llamar al método real que estamos testeando pasándole los parámetros. Pero aquí nosotros podríamos poner Asserts adicionales, que se comprobarían para todos los unit tests de Pex. El código de un unit test de Pex es similar a:

[TestMethod]
[PexGeneratedBy(typeof(StringExtensionsTest))]
public void Right04()
{
    string s;
    s = this.Right("\0\0\0", 1);
    Assert.AreEqual<string>("\0", s);
}

La llamada a this.Right es la llamada al PUT que ha generado antes.

Os dejo un par de videos con más información sobre Code Contracts y Pex para que les echeis un vistazo, dado que es un tema que vale realmente la pena!

Saludos!

IoC o el poder de ceder el control

Eduard Tomàs i Avellana — Tue, 28 Oct 2008 10:09:00 GMT

Hablando con colegas de profesión, me he dado cuenta de que muchos de ellos no terminan de comprender el patrón IoC o las ventajas que su uso comporta… Así que sin ánimo de sentar cátedra he decidido escribir este post, por si le sirve a alguien… J

IoC, que corresponde a las siglas de Inversion Of Control, agrupa a varios patrones que tienen en común que el flujo de ejecución del programa se invierte respecto a los métodos de programación tradicionales (wikipedia dixit). Generalmente el programador especifica las acciones (métodos) que se van llamando, pero en IoC lo que se especifican son las respuestas a determinados eventos o sucesos, dejando en manos de un elemento externo todas las acciones de control necesarias cuando lleguen estos sucesos.

Un claro ejemplo de IoC se encuentra en el modelo de eventos de Windows Forms. Cuando vinculamos una función gestora a un evento (p.ej. el Click de un Button), estamos definiendo la respuesta a un determinado evento y nos despreocupamos cuando se llamará a nuestra función gestora. Es decir, cedemos el control del flujo al framework para que sea él que llame cuando sea necesario a nuestro método.

Una de las principales ventajas de usar patrones IoC es que reducimos el acople entre una clase y las clases de las cuales depende, y eso cuando queremos utilizar por ejemplo tests unitarios es muy importante (no seré yo quien hable ahora de las ventajas de TDD cuando ya lo ha hecho Rodrigo (http://geeks.ms/blogs/rcorral/archive/2006/12/02/beneficios-y-carater-iacute-sticas-de-un-buen-test-unitario.aspx)). De los distintos patrones IoC me interesa comentar específicamente dos: Service Locator y cómo podemos usarlo en .NET. Para más adelante dejo Dependency Injection, otra forma de IoC que también es extremadamente útil.

Id a la nevera, coged una Voll-Damm o cualquier otra cervecilla y sentaos que este post es un poco largo… J

Service Locator

El objetivo de Service Locator es reducir las dependencias que tenga una clase. Imaginemos una clase, que depende de otras dos clases (p.ej. ServicioSeguridad y ServicioLogin). Podríamos tener un código tal como:

class Client

{

static void Main(string[] args)

{

new Client().Run();

}

private void Run()

{

// En este punto necesitamos objetos de las clases ServicioSeguridad y ServicioLogger

ServicioSeguridad ss = new ServicioSeguridad();

ServicioLogger sl = new ServicioLogger();

//...

}

En este punto tenemos un fuerte acople entre la clase Client y las clases ServicioSeguridad y ServicioLoggger. Seguiríamos teniendo este mismo acople incluso aunque utilizáramos interfaces porque deberíamos hacer el "new":

IServicioSeguridad ss = new ServicioSeguridad();

IServicioLogger sl = new ServicioLogger();

Las principales desventajas de esta situación son:

Las clases que implementan las dependencias (en nuestro caso ServicioSeguridad y ServicioLogger) deben estar disponibles en tiempo de compilación (no nos basta con tener solo las interfaces).
El fuerte acople de la clase con sus dependencias dificulta de sobremanera su testing. Si queremos utilizar Mocks para de ServicioSeguridad o ServicioLogger vamos a tener dificultades

El patrón de ServiceLocator soluciona estos dos puntos, sustituyendo las dependencias de la clase Client por dependencias a los interfaces y a un elemento externo, que llamaremos Contenedor encargado de devolver las referencias que se le piden.

Cuando la clase necesita un objeto en concreto, lo pide al contenedor:

IServicioSeguridad ss = container.Resolve<IServicioSeguridad>("servicioseguridad");

IServicioLogger sl = container.Resolve<IServicioLogger>("serviciologger");

El método Resolve devolvería una referencia del tipo especificado en el parámetro genérico de acuerdo con un identificador. Evidentemente falta alguien que cree el contenedor y que agregue los servicios a él. Es decir, en algún sitio habrá algo como:

container = new IoCContainer();

container.Add<IServicioSeguridad, ServicioSeguridad>(new ServicioSeguridad(), "servicioseguridad");

container.Add<IServicioLogger, ServicioLogger>(new ServicioLogger(), "serviciologger");

La gran diferencia es que esto no tiene porque estar en la clase Client. Simplemente pasándole a la clase Client una referencia al contenedor, eliminamos todas las dependencias de la clase Client con las clases que implementan los servicios. Y donde creamos el contendor? Pues depende… si estamos en nuestra aplicación, lo podemos crear en el método que inicialice la aplicación, pero si queremos probar la clase Client con tests unitarios podemos crear el contenedor en la inicialización del test…. Y lo que es mejor: rellenarlo con Mocks de los servicios!

Así, nuestro programa podría tener una clase Bootstrapper que crea el contenedor de IoC y lo inicializa con los objetos necesarios:

class Bootstrapper

{

static void Main(string[] args)

{

IIoCContainer container = new IoCContainer();

container.Add<IServicioSeguridad, ServicioSeguridad>(new ServicioSeguridad(), "servicioseguridad");

container.Add<IServicioLogger, ServicioLogger>(new ServicioLogger(), "serviciologger");

new Client(container).Run();

}

Pero si queremos usar tests unitarios de la clase Client, podemos cambiar los objetos por Mocks fácilmente:

[ClassInitialize]

public static void Init(TestContext context)

{

container = new IoCContainer();

container.Add<IServicioSeguridad, ServicioSeguridadMock>(new ServicioSeguridadMock(), "servicioseguridad");

container.Add<IServicioLogger, ServicioLoggerMock>(new ServicioLoggerMock(), "serviciologger");

}

[TestMethod]

public void TestMethod1()

{

Client c = new Client(container);

c.Run(); // Este método Run usará los Mocks!

}

Fijaos que podemos lanzar tests unitarios sobre la clase Client, sin necesidad alguna de cambiar su código y utilizando Mocks. Además, la clase Client no tiene ninguna dependencia con las implementaciones de los servicios que utiliza, así que no es necesario ni que existan para poder crear la clase Client (sólo necesitamos las interfaces).

Unity

Aunque existen varios contenedores IoC open source para .NET, Microsoft tiene el suyo, también open source, llamado Unity (http://www.codeplex.com/unity/). Unity proporciona soporte para los patrones Service Locator y Dependency Injection.

Para que veais un poco su uso he dejado un proyecto de herramienta de línea de comandos para listar los ficheros de un directorio (vamos un dir, jejejee…. J).

La solución está dividida en varios proyectos:

DemoIoC: Contiene el Bootstrapper, la clase que inicializa el contenedor de Unity, agrega la clase llamada ServicioFicheros y utiliza un objeto Cliente para realizar las acciones de la línea de comandos.
Cliente: Contiene la implementación de la clase Cliente.
Interfaces: Contiene las interfaces del servicio (en este caso sólo una)
Implementations: Contiene las implementaciones del servicio (en este caso sólo una)
Mocks: Contiene las implementaciones de los Mocks (en este caso sólo una)
UnitTests: Contiene tests sobre la clase Cliente, usando un Mock del servicio ServicioFicheros.

El ejecutable (proyecto DemoIoC, assembly DemoIoC.exe) es un archivo de línea de comandos que acepta dos parámetros:

DemoIoC –l para listar todos los ficheros (del directorio actual)

DemoIoC –e:fichero.ext Indica si el fichero "fichero.ext" existe (en el directorio actual).

Si lo ejecutáis veréis que NO funciona bien: lista los ficheros correctamente, pero devuelve que un fichero existe cuando no es cierto y viceversa. Si miráis el código de la clase Cliente, encontrareis el error, ya que es obvio, pero lo bueno es que el proyecto UnitTest, testea este método de la clase Cliente, usando un Mock del ServicioFicheros y el UnitTest detecta el error. Observad lo fácil que ha sido sustituir el ServicioFicheros por un Mock sin alterar la clase Cliente, gracias al uso del patrón Service Locator!

PD: Estooooo... que me he dejado de adjuntar el código de ejemplo... Lo teneis aquí!!!

Saludos!!!

Referencias

Os dejo algunas referencias para su lectura por si os interesa profundizar un poco en el tema tratado:

Unity Container (http://www.codeplex.com/unity/)
Patrón Service Locator (http://msdn.microsoft.com/en-us/library/cc707905.aspx)
Inversion of Control (http://msdn.microsoft.com/en-us/magazine/cc947917.aspx)
Mocks (http://martinfowler.com/articles/mocksArentStubs.html)