Siguiente Post
Estoy escribiendo una serie de posts sobre escribir un intérprete usando TDD (Test-Driven Developement). Mi intención es mostrar el uso de TDD en código de producción. Desde mi adopción de TDD, produzco mejor código (eso espero ;-) y en menos tiempo (no más largas sesiones de depuración ;-). Hay otros beneficios: si tenemos una aplicación con TDD, tenemos un buen code coverage (cubrimiento de código), y escribimos los casos de uso del código de la aplicación y los resultados esperados. Todo esto da confianza para mejorar la aplicación, posiblemente por otro equipo. Pienso que entregar una aplicación con TDD es un plus para el cliente final y para la evolución saludable de software exitosa. Podemos tener lo mismo con simples tests, pero TDD agregar el correcto proceso iterativo para armar código de producción, en vez de dejar los tests “para después”.
Pero el ejemplo de intérprete que estoy armando es una especie de “largo code kata”. Podrían decir: “Eh! No es la clase de código que escribo todos los días”. Sí, es verdad. Entonces, es tiempo de comenzar una serie de posts escribiendo una aplicación.
Elegí estas tecnologías para usar:
- .NET 3.5 (puede que pase en algún momento a 4.0)
- ASP.NET MVC 2 (podría usar la versión 3)
- Visual Studio 2008 (el otro candidato es VS 2010), usando su soporte de tests, como en mis anteriores posts.
Tengo que seleccionar una tecnología de persistencia. Esoy pensando en NHibernate 3.x + Fluent NHibernate o con ConfORM; La alternativa es Entity Framework 4 with Code First.
Hay dos caminos a seguir, en este ejemplo iterativo:
- Dominio simple: comenzar escribiendo código de presentación y tests, entonces pasar a una capa de aplicación/servicios, y de ahí, pasar a la capa de persistencia
- Un dominio más complejo: escribir el código del dominio con tests, recién ahí pasar a la presentación y a la persistencia.
El primer camino es un tipo de aproximación “top-down”. Es opuesto a lo que he usado en mi serie de intérprete (noten la ausencia de mocks, stubs, en mi camino “bottom-up”, escribiendo expresiones, comandos, pasando a parte del lexer, luego al parser, etc…). Ahora, con esta nueva forma de hacer TDD, quiero mostrar el armado incremental de funcionalidad, aún sin tener una base de datos, modelo de persistencia, y otros detalles tecnológicos desde el principio. ASP.NET MVC y TDD nos permiten escribir los casos de uso iniciales de una manera simple, en un dominio simple, abrazando un desarrollo ágil e incremental. Otro beneficio es que podemos entregar algo “que funciona” para obtener "feedback" temprano del usuario.
Luego de explorar esta forma de hacer desarrollo con TDD, cambiaré a un dominio un poco más complejo. En esos casos, yo prefiero comenzar escribiendo el dominio con tests, enfocándome en el núcleo de la aplicación, agregarn en el camino algo de presentación, para mostrar algo al usuario final, pero sin gastar mucho tiempo en temas complejos de interfaz (AJAX, javascript, interfaz dinámica en el browser).
El formato de escribir una serie de post es importante: hay muchos ejemplos de código de aplicaciones con TDD (por ejemplo, muchos proyectos de código abierto), pero muchos de esos ejemplos muestran “la etapa final” de un largo camino. Escribiendo un ejemplo más simple, incrementalmente, es una mejor forma de comenzar a comprender el estilo TDD de hacer desarrollo de software.
Bueno, suficiente por hoy. Este es un post de introducción, para presentar la idea, y comenzar a calentar motores! Comentarios, sugerencias, bienvenidas!.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez