Angel "Java" Lopez : TDD, Desarrollo Agil

TDD Kata (4): La cortadora de césped

lopez — Sat, 20 Apr 2013 17:42:46 GMT

Como comentaba en el anterior post, hace una semana participé de la ronda preliminar del Google Code Jam.

El ejercicio B fue el Lawnmover:

https://code.google.com/codejam/contest/2270488/dashboard#s=p1

Problem

Alice and Bob have a lawn in front of their house, shaped like an N metre by M metre rectangle. Each year, they try to cut the lawn in some interesting pattern. They used to do their cutting with shears, which was very time-consuming; but now they have a new automatic lawnmower with multiple settings, and they want to try it out.

The new lawnmower has a height setting - you can set it to any height h between 1 and 100 millimetres, and it will cut all the grass higher than h it encounters to height h. You run it by entering the lawn at any part of the edge of the lawn; then the lawnmower goes in a straight line, perpendicular to the edge of the lawn it entered, cutting grass in a swath 1m wide, until it exits the lawn on the other side. The lawnmower's height can be set only when it is not on the lawn.

Alice and Bob have a number of various patterns of grass that they could have on their lawn. For each of those, they want to know whether it's possible to cut the grass into this pattern with their new lawnmower. Each pattern is described by specifying the height of the grass on each 1m x 1m square of the lawn.

The grass is initially 100mm high on the whole lawn.

Lo pude solucionar, ver:

https://github.com/ajlopez/TddOnTheRocks/tree/master/Lawnmover

Como siempre, la historia, prácticamente por test:

https://github.com/ajlopez/TddOnTheRocks/commits/master/Lawnmover

Pude resolver el primer “set” pequeño de problemas que me entregó Google. No pude resolver el “set” grande, porque me equivoqué de algoritmo a seguir, y no cumplí en resolverlo en 8 minutos. Mi algoritmo inicial (pueden ver los commits) resolvía el problema partiendo de los números mayores. Lo cambié para que comenzara a resolver los números menores primero, y ahí anduvo más rápido. Un tema que aprendí: algunos problemas de Google Code Jam son difíciles de probar a mano, como no tenemos los casos de uso (entrada y salida esperada), hay que trabajar con cuidado en esos temas.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD Kata (3): TaTeTíTomek

lopez — Mon, 15 Apr 2013 10:41:00 GMT

Anterior Post
Siguiente Post

El sábado pasado estuve participando del Google Code Jam. El ejercicio A fue TicTacToeTomek:

https://code.google.com/codejam/contest/2270488/dashboard

Problem

Tic-Tac-Toe-Tomek is a game played on a 4 x 4 square board. The board starts empty, except that a single 'T' symbol may appear in one of the 16 squares. There are two players: X and O. They take turns to make moves, with X starting. In each move a player puts her symbol in one of the empty squares. Player X's symbol is 'X', and player O's symbol is 'O'.

After a player's move, if there is a row, column or a diagonal containing 4 of that player's symbols, or containing 3 of her symbols and the 'T' symbol, she wins and the game ends. Otherwise the game continues with the other player's move. If all of the fields are filled with symbols and nobody won, the game ends in a draw. See the sample input for examples of various winning positions.

Given a 4 x 4 board description containing 'X', 'O', 'T' and '.' characters (where '.' represents an empty square), describing the current state of a game, determine the status of the Tic-Tac-Toe-Tomek game going on. The statuses to choose from are:

"X won" (the game is over, and X won)

"O won" (the game is over, and O won)

"Draw" (the game is over, and it ended in a draw)

"Game has not completed" (the game is not over yet)

If there are empty cells, and the game is not over, you should output "Game has not completed", even if the outcome of the game is inevitable.

Se nos da un archivo de entrada con distintas posiciones de tablero, y tenemos que producir una salida diciendo si X ganó, O ganó, empate, o todavía falta completar el juego.

Lo resolví usando TDD, y pueden ver el resultado en:

https://github.com/ajlopez/TddOnTheRocks/tree/master/TicTacToeTomek

Y la historia, prácticamente con commits por tests, en:

https://github.com/ajlopez/TddOnTheRocks/commits/master/TicTacToeTomek

Fue un ejercicio sencillo, y bien adaptado para TDD. Google me aceptó tanto la solución de un archivo de entrada pequeño, y de otro grande. Tengo que escribir sobre los otros ejercicios (B, C, D), que se complican por:

- Hay que resolver el problema en un tiempo adecuado

- El algoritmo a implementar no es evidente, o no se puede implementar “de a poco”, con “baby steps”, con lo que a veces hay grandes refactor

- A veces, dada la entrada, es difícil calcular la salida correcta, aún manualmente. Entonces, muchos de mis intentos fueron rechazados al subir el archivo solución a Google.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD Kata (2): Lenguaje Alienígena

lopez — Fri, 12 Apr 2013 13:03:00 GMT

Anterior Post
Siguiente Post

En la lista TDDev en español se mencionó hace poco el Google Code Jam. Uno de los pasados desafíos de esa competencia, es el Alien Language.

After years of study, scientists at Google Labs have discovered an alien language transmitted from a faraway planet. The alien language is very unique in that every word consists of exactly L lowercase letters. Also, there are exactly D words in this language.

Once the dictionary of all the words in the alien language was built, the next breakthrough was to discover that the aliens have been transmitting messages to Earth for the past decade. Unfortunately, these signals are weakened due to the distance between our two planets and some of the words may be misinterpreted. In order to help them decipher these messages, the scientists have asked you to devise an algorithm that will determine the number of possible interpretations for a given pattern.

A pattern consists of exactly L tokens. Each token is either a single lowercase letter (the scientists are very sure that this is the letter) or a group of unique lowercase letters surrounded by parenthesis ( and ). For example: (ab)d(dc) means the first letter is either a or b, the second letter is definitely d and the last letter is either d or c. Therefore, the pattern (ab)d(dc) can stand for either one of these 4 possibilities: add, adc, bdd, bdc.

Me gustó como problema. Vean en la página que también se pide leer un archivo de entrada con las palabras y los patrones a procesar. Se pueden bajar archivos de entrada desde la página del problema, y se debe entregar un archivo de salida para que Google nos diga si está bien. Hoy escribí una solución usando TDD:

https://github.com/ajlopez/TddOnTheRocks/tree/master/AlienLanguage

Pueden ver la historia de los commits, prácticamente por test:

https://github.com/ajlopez/TddOnTheRocks/commits/master/AlienLanguage

Una de las últimas cosas que hice fue refactorizar, para mejorar, si fuera necesario, la detección de palabras que cumplen con un patrón. Podría mejorarlo más, por ejemplo, haciendo que en vez de tener una lista de palabras, mantener un árbol de palabras con ramas por letra, como hice en SimpleBoggle.

Al final, escribí un programa de consola que acepta un archivo de entrada y produce un archivo de salida como pide Google. Me bajé un archivo grande de Google, lo procesé, y la salida obtenida lo subí a Google, para que lo revise automática. Y dió bien:

Otro triunfo de TDD ;-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD Kata (1): Piedra Papel Tijera Lagarto Spock

lopez — Wed, 10 Apr 2013 14:43:00 GMT

Siguiente Post

En estos días, leí en la lista de TDDev en español una nueva kata publicada en el blog de Aprendiendo TDD:

Piedra Papel Tijera Lagarto Spock

basado en el problema publicado en

http://www.solveet.com/exercises/Kata-Piedra-Papel-Tijera-Lagarto-Spock/20

Tomé la descripción del artículo de la Wikipedia:

http://en.wikipedia.org/wiki/Rock-paper-scissors-lizard-Spock

The rules of Rock-paper-scissors-lizard-Spock are:

Scissors cut paper

Paper covers rock

Rock crushes lizard

Lizard poisons Spock

Spock smashes (or melts) scissors

Scissors decapitate lizard

Lizard eats paper

Paper disproves Spock

Spock vaporizes rock

Rock breaks scissors

Y entonces me puse a codificarla usando TDD. Pueden ver el resultado en:

https://github.com/ajlopez/TddOnTheRocks/tree/master/SpockGame

La historia, casi por tests:

https://github.com/ajlopez/TddOnTheRocks/commits/master/SpockGame

Vean el primer test/commit: todavía no compilaba. Luego, comenzó a compilar pero con estado rojo. Luego, lo pasé a verde y así.

También decidí ter dos tests por cada combinación de arriba: una que prueba que Scissors cut Paper, y otra que prueba Paper is cut by Scissors

El diseño inicial fue basado en:

- Tener una instancia de Game (la alternativa era tener la clase, sin instancia)

- Tener una enumeración para las opciones de juego (Play.Scissors, etc…)

- Tener una enumeración para el resultado (PlayResult.Tie, PlayResult.FirstPlayer…)

En vez de tener resultado de juego, podría haber puesto un método que comparara dos opciones de juego, y devolviera cuál es la que gana. Incluso hoy podría poner este método como refactorización.

Vean la última refactorización: podría haber dejado el código de implementación tal como estaba, con if para decidir cuándo gana el primer jugador:

Por esta otra forma:

sugerida por el artículo de la Wikipedia:

One way to remember the rules is to remember the standard "rock-paper-scissors" ordering, where each gesture defeats the one before it, and is defeated by the one after. But then add the two novel gestures near the word they approximately rhyme with:

Rock

Spock

Paper

Lizard

Scissors

In this expanded list, each gesture is defeated by the following two options, and defeats the preceding two.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Escribiendo una Aplicación usando TDD (Part 6) Modificando Vistas

lopez — Sun, 07 Apr 2013 11:33:39 GMT

Anterior Post

El post de hoy va a mostrar que, al haber usado MVC (Model-View-Controller) podemos modificar nuestras vistas, sin necesidad de tocar el código. Ni siquiera tenemos que recompilar, en muchos casos.

Primero, una novedad: he pasado el ejemplo, paso a paso, a ASP.NET MVC 4, usando Visual Studio 2010. Y también lo pasé a mi cuenta de GitHub

https://github.com/ajlopez/TddAppAspNetMvc

Vean que cada versión (cada entrega por post) está señalada por tags. La de este post es la 0.0.5. Siempre pueden ver en

https://github.com/ajlopez/TddAppAspNetMvc/commits/master

Una de las cosas nuevas que me dió esta versión de ASP.NET MVC es el soporte de Razor, ahora las vistas están escritas con Razor. Como en el anterior post, use los “wizard” de creación de vistas del propio Visual Studio, y luego las modifiqué un poco (apenas algun texto).

En el paso de este post, lo que hice fue agregar Twitter Bootstrap:

Agregué estilos y javascript que necesita Bootstrap, y armé un _viewstart.chtml que le indica a Razor que todas las vistas usan un _Layout.cshtml

Vean cómo se ve ahora la página de Subjects:

Notablemente, no toqué nada de código ni de tests. Esto muestra que hasta se puede trabajar en paralelo, o en distintos tiempos: primero se arma el código de los controladores y acciones con tests. Luego, al mismo tiempo o en algun momento, se agregan y mejoran las vistas.

Próximos posts: agregar libros, aparición de primeros servicios, modelo de negocio, etc.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Introducción a TDD con Visual Studio

lopez — Wed, 27 Mar 2013 10:03:55 GMT

Gracias a la gente del MUG Argentina (http://www.mug.org.ar), dí una charla de dos horas sobre cómo es TDD, con un ejemplo en Visual Studio.

Desarrollamos algunos tests, cumpliendo con el ciclo rojo, verde, refactor, sobre una Factura con Productos y Cantidades. Pueden ver el código en:

https://github.com/ajlopez/TddOnTheRocks/tree/master/Ventas

Los commits, con la evolución paso a paso, están en

https://github.com/ajlopez/TddOnTheRocks/commits/master

Mencioné algunos posts en la charla. Son mis posts sobre TDD, pero destaqué:

Escribiendo un intérprete en .NET (Parte 10) donde van a ver un caso distinto y más extenso

TDD y Diseño de Implementación (1) donde voy a escribir sobre cómo queda simple el diseño de implementación usando TDD y la cabeza

TDD como Compilador para ver cómo TDD es el compilador de estos años: nos avisa cuando algo está mal, mucho mejor que los compiladores de lenguajes tipados

TDD y Base de Datos sobre alternativas de qué hacer cuando tenemos bases de datos en nuestros tests

TDD y Baby Steps sobre ¿cómo comerse un elefante? Pedacito a pedacito

TDD y el juego del Go sobre “el sistema está en buena forma” a cada momento, listo para abrazar el cambio y los próximos casos de uso.

TDD, Test Unitarios y Mocks sobre usar mocks solamente cuando es necesario.

TDD y Casos de Uso sobre cómo ir acompañando la implementación de casos de uso con TDD. Lean el post de “Uncle Bob” No DB

Escribiendo una Aplicación usando TDD (parte 5) sobre algunos pasos que se pueden dar con ASP.NET MVC

Para los que quieran ver cómo desarrollo partiendo de los controllers, en vez que desde el dominio de negocio, ver

Desarrollando una aplicación con TDD desde 0

donde por temas de tiempo, me salteé la evolución guiada por casos de uso. Pero ahí se ve cómo van surgiendo patrones, arquitectura, reparto de responsabilidades, pero PRIMERO LOS TESTS!

Para practicar, coleccioné algunos enlaces en:

http://delicious.com/ajlopez/tdd+codekata

Para aprender más:

https://delicious.com/ajlopez/tdd+tutorial

Para ejemplos en video:

https://delicious.com/ajlopez/tdd+video

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Entrevista y Podcast

lopez — Sat, 23 Mar 2013 10:47:32 GMT

Hoy paso a comentar dos entregables que se publicaron: una entrevista, y una charla como podcast.

El año pasado, el bueno de @santiagobasulto (desarrollador de software, emprendedor, programador Python, colaborador en proyectos de código abierto) tuvo la paciencia de hacerme una entrevista en persona, acá en Buenos Aires, tomándose el trabajo de viajar desde su La Plata en un día atareado. Estuvimos charlando como dos horas (en un bar histórico de la ciudad, donde se filmó la escena del billete y el mozo, de la película “Nueve Reinas”, les dejo como trabajo para el hogar averiguar cuál es). Justamente, ese bar tiene también algo que ver con la entrevista, porque he pasado por él varias veces en las décadas que llevo de programar.

Santiago la pasó en limpio, la pueden leer en:

http://charliedontcode.com/entrevistas/2012/08/12/entrevista-angel-java-lopez.html

Algo más de contexto, lo escribí hace algo más de cuatro años:

http://msmvps.com/blogs/lopez/archive/2008/12/31/treinta-a-241-os-en-desarrollo-de-software.aspx

Visiten el blog de Santiago:

http://charliedontcode.com/

Muy buena la escena de cine de donde toma el nombre (ya me imagino a @santiagobasulto cruzándose con Robert Duvall, acá en Buenos Aires, supongo que en otro bar histórico, La Biela ;-).

Y también tuve una charla, esta vez a distancia, con los buenos @roundcrisis @dvilchez, publicada hoy como podcast:

http://www.32minutos.net/?p=106

Ah! Pusieron una foto mía, debe ser la “clásica” ;-) (no me saco muchas fotos). Tratamos temas de desarrollo de software, algo de desarrollo ágil, insistí bastante sobre el tema TDD, también sobre generación de código como sistema experto, y “ver la luz”. Y hasta apareció algo de Anglish ;-).

Vean que han producido varios podcast en:

http://www.32minutos.net/

como el de Programación Funcional con el bueno de @martinsalias, o el de Node.js con @woloski, @jfroma y @theprogrammer. Hace unas semanas grabamos otro podcast, esta vez con Martin, para 32 minutos, y se conversó bastante sobre agilidad. Veremos si queda publicado en estos días. Estén atentos.

Les agradezco a los tres haberme permitido conversar y expresar algunas ideas, que pueden servir o no.

Pero lo bueno que están haciendo, es dejar entregables consumibles. Eso es importante. Internet (y la Web en particular) está permitiendo la generación de contenido y compartirlo con todos los interesados, de una forma accesible. Pienso que es una revolución tan grande como la de Gutenberg, y los primeros libros de Manuccio.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Charla de TDD con Visual Studio en Buenos Aires

lopez — Sat, 16 Mar 2013 15:35:08 GMT

Gracias al MUG Argentina podré dar en unos días una gratuita charla sobre TDD con Visual Studio:

Introducción a TDD con Visual Studio

Martes 26 de Marzo

Lugar: Auditorio del MUG, Rivadavia 1479 1er Piso, Buenos Aires.

Horario: 18:30 a 20:30 hs.

Describiremos brevemente lo que es y no es Test-Driven Development, pasando luego a escribir código.
Armaremos un dominio simple, usando TDD, y el ciclo de: test, rojo, verde, refactor. Veremos como entonces va “creciendo” nuestro código de manera orgánica, consiguiendo un diseño adecuado a lo que se necesita.

Los tests nos guían en la construcción del software, siendo más que tests, especificaciones, ejemplos de uso esperado del software en construcción y hasta conseguimos ser más productivos y con código mantenible, evitando la sobre-ingeniería, y arquitecturas complicadas.

Es gratuito, pero hay que registrase aquí.

Ya saben que TDD es uno de mis temas favoritos. Pero ¿por qué? Porque es la disciplina de programación que pone en marco y contexto todas las demás. Si saben SOLID, patrones y “tutti li fiocci” pero no hacen TDD, será hacer lo bueno, pero no lo correcto. Será como alinear las sillas en la cubierta del Titanic ;-)

No quiero aburrirlos más, ya escribí bastante en mis posts sobre TDD. Y cada día publico código que sigue TDD en mi cuenta de GitHub.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD y Diseño de Implementación (1)

lopez — Fri, 08 Mar 2013 14:19:53 GMT

Sirva el post de hoy como introducción a un gran tema, que seguramente no podré comentar completamente. Es el tema de la relación entre TDD (Test-Driven Development) y diseño de implementación (no de interfaz o experiencia de usuario, digamos, diseño del código y su arquitectura).

Comienzo con una pregunta:

¿Qué esperamos de un sistema o aplicación?

Lo primero que se me ocurre, es que funcione bien. Imaginemos que estamos usando un procesador de texto, y cuando guardamos el documento se graba nada más que la mitad y lo demás se pierde. No será lo que esperamos. A esta altura de la historia del software, esperamos que una aplicación funcione bien, sin ese tipo de problemas. Yendo más específico, debería:

- Brindar la salida esperada, ante una entrada esperada

- Reaccionar de forma adecuada, ante una entrada no esperada

- Reaccionar de forma adecuada ante una falla en el entorno (por ejemplo, pérdida de conexión con la base de datos)

Seguramente se les ocurriran más puntos de este estilo.

Ahora bien, me puedo imaginar una aplicación así, y que no esté bien diseñada. Muchos de nosotros recordamos (y aún puede ser que tengamos) aplicaciones Visual Fox, o Visual Basic clásico, donde todo está escrito en el botón de aceptar. Conozco aplicaciones así, que funcionan según lo esperado. Y los clientes y usuarios están contentos.

Pero muéstrenme un ejemplo de una aplicación exitosa así, y casi seguro que los creadores de ese sistema tuvieron que lidiar bastante en sacar nuevas versiones, y todavía están viendo cómo migrarlas a la web y dispositivos móviles, impulsados por lo que la gente y el mercado espera hoy.

Entonces ¿qué esperamos de un buen diseño de implementación? No sé ustedes, pero yo espero que el diseño de implementación (el código, su funcionalidad interna, su distribución, su arquitectura) sea simple. ¿Por qué? Porque es la cualidad más importante para conseguir que sea mantenible.

Si un sistema exitoso no necesitara cambios, no buscaríamos mantenibilidad. Pero si un sistema es exitoso, casi seguro que sobrevivirá en el tiempo, y como la realidad cambia, habrá que actualizarlo. Un contraejemplo: si conseguimos escribir un sistema que nos dé el número ganador de la próxima gran lotería en EE.UU. y de sólo esa lotería, con un grandísimo premio, el cliente final no se va a preocupar por la mantenibilidad o nos va a pedir actualizaciones. Pero en general, los sistemas y aplicaciones exitosos necesitan evolucionar.

Por supuesto, podemos conseguir sistemas y aplicaciones exitosos programando sin buen diseño, por ejemplo, para llegar primeros a un mercado. Algunas de las aplicaciones Visual Fox que mencionaba antes, al salir rápidamente, consiguieron que la empresa creadora pudiera llegar primero a un nicho de mercado, y eso fue más importante que el tener un buen diseño desde el comienzo. Luego, se pudo pagar la deuda técnica en la versión 2.x con todo el ingreso y el posicionamiento que se consiguión en la versión 1.x.

Entonces, volviendo a la mantenibilidad, ¿por qué pido que la implementación sea simple? Porque será entonces

- más entendible para quien quiera que venga (individuo o equipo) a escribir la versión 2.0

- tendrá menos piezas, y cada modificación se podrá encarar tocando pocas de esas piezas a la vez

Por añadidura, una aplicación internamente simple, se verá expuesta a menos fallas de las piezas (en general) por tener menos puntos de posibles problemas en ejecución. No es lo mismo tener una aplicación que actualice una sola base de datos, que otra que tenga que actualizar 10 bases de datos distribuidas y heterogéneas.

Hay quien pedirá: no, yo no quiero que el diseño sea simple, sino flexible. Acá llegamos a un punto crucial, para lo que quiero tratar y todavía no apareció: desarrollar con TDD.

Bien, bastante por hoy, veré de escribir en próximos posts:

- Lo simple vs lo flexible

- Cómo TDD promueve lo simple

- Cómo TDD nos ayuda a conseguir lo “flexible” por añadidura y sin gran esfuerzo

- Cómo TDD nos da una mano para conseguir lo primero que mencioné: que la aplicación funcione como esperamos

- Cómo un buen diseñador puede diseñar “mejor” con TDD, y además cómo eso beneficia a quien quiera que venga a mantener el sistema

Vean que pongo “TDD promueve”, “TDD nos ayuda”, porque TDD solo no hace nada. Hay que poner cabeza. Pero desde hace unos años veo que TDD + Cabeza, nos da un sistema mejor que sólo aplicar Cabeza, es decir, sólo con nuestros conocimientos y destrezas.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD como Compilador

lopez — Wed, 20 Feb 2013 17:56:01 GMT

Veamos hoy un tema que pone en perspectiva ¿para qué sirve TDD? O por lo menos, trata de responder en gran parte esa pregunta.

Todos conocemos lo que es programar en Java o en .NET. Escribimos el programa, posiblemente usando una IDE (Eclipse, Visual Studio.NET), y llegado el momento, compilamos. Los lenguajes .NET (VB.NET, C#, otros) y Java, son lenguajes tipados. El compilador nos dice cuándo nos equivocamos, ANTES de ejecutar nuestro programa. Por ejemplo, nos dice que nos equivocamos en el nombre de un método, o que escribimos mal el nombre de una clase, o que está mal el tipo del parámetro que tenemos que pasar a una función.

Eso ha sido útil por décadas. Y entonces, es fácil confundir esa solución (detectar en compilación errores), con el problema inicial (que nuestra aplicación funcione como esperamos).

Cuando pasamos a lenguajes dinámicos, como Ruby o Python o JavaScript, algunos se resienten: hey! No tenemos compilador! No podemos asegurarnos que lo que escribimos esté bien. Sólo nos damos cuenta si lo ejecutamos. Esto parece inclinar la balanza de nuestras preferencias a los lenguajes tipados con compilación.

Pero no es así. Todos los compiladores del mundo NO PUEDEN ASEGURARNOS que lo que escribimos esté bien. No pueden asegurarnos, al compilar, QUE NUESTRO SOFTWARE HAGA LO QUE ESPERAMOS QUE HAGA.

Veamos un ejemplo en concreto. Si tenemos un método llamado “incrementar” que recibe un entero, un compilador de Java o de .NET nos va a avisar sin lo llamamos con un nombre incorrecto, o si le estamos pasando un valor real o texto en lugar de un entero. Y eso es útil. PERO NO NOS AVISA NADA sobre si el método “incrementar” cumple con lo que esperamos de él. Bien podríamos tener en ese método código que en vez de incrementar una variable interna se dedica a formatear el disco C: o a borrar todo lo que tengamos en /usr/bin. EL COMPILADOR NO NOS SIRVE para afirmar que el método hace lo que esperamos que haga.

En cambio, TDD, al escribir los tests de lo que esperamos de nuestro método “incrementar” NOS AVISA cuándo las expectativas que tenemos no se cumplen. Entonces, no hay mucha diferencia entre escribir Ruby sin compilar y sin TDD y escribir C# sin compilar y sin TDD: de las dos formas, no sabemos si lo que escribimos HACE LO QUE ESPERAMOS QUE HAGA.

Es por todo eso que veo a TDD como la próxima generación de compiladores: es lo que nos asegura que lo que escribimos esté bien, NO EN SINTAXIS, sino en lo que podemos nombrar como SEMANTICA: lo que escribimos cumple con la conducta esperada.

Accesorio: por eso no tomo tanto en cuenta a los que critican a Ruby, Python o JavaScript por no ser tipados y no poder detectar errores en “compilación”. Si escribimos siguiendo TDD, no importa tanto el lenguaje que usemos: cada línea de código que agregamos está respaldada por un test, y cada test es una condición que cumplir. Cuando TDD nos avise que un test está en rojo, es como cuando el compilador nos avisa “el método inkrementar no existe”. Es más: yo diría que nos das avisos más importantes que lo que nos da cualquier compilador.

Escribir código de producción sin TDD, es como escribir un programa ejecutable, usando un editor hexadecimal sobre el archivo compilado: nada nos asegura que lo que estamos haciendo esté bien. Si quieren escribir código de producción sin TDD, bien, tengo unos folletos para jugar ruleta rusa, si les interesa ;-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD y Base de Datos

lopez — Mon, 18 Feb 2013 16:54:30 GMT

Ya he escrito bastante en mis anteriores posts, sobre cuánto uso modelos en memoria al desarrollar un sistema. Pero ¿qué pasa cuando tenemos una base de datos? Ya sea porque llegamos al punto de necesitar usarla, o porque la base de datos ya está desde el principio del desarrollo.

Lo que he encontrado que me ha servido en esos casos es tener los tests de TDD como siempre, pero el modelo con persistencia en una base de datos local, del desarrollador. En el repositorio común al equipo debería estar claros los pasos para instalar esa base de datos (por ejemplo, un script de creación e inserción de datos iniciales). Puede que esa misma base de datos la usemos localmente para hacer pruebas manuales y demostraciones. Pero la cuestión es que los tests de TDD debería poder ejecutarse en cualquier momento, una vez o varias veces, sin verse afectado por la base de datos. Entonces, hay varias soluciones (que se pueden combinar):

- Un comando de línea que ponga a la base de datos de TDD en un estado conocido, la “well-known database”

- Tener una base de datos para TDD y otra, también local, para las demostraciones

- En los tests, una vez, al principio, tener una tarea que ponga a la base de datos de TDD en un estado conocido

- Cada test, envolverlo en una transacción y nunca hacer el commit

Con esto, se reduce la fricción de correr los tests locales.

En un servidor de integración continua, seguramente se creará la base y se cargará con los datos iniciales antes de correr los tests (de TDD u otros)

Yendo un poco más en detalle. Supongamos que nuestro sistema debe calcular la retención del impuesto a las ganancias cuando hay que pagar a un proveedor. En Argentina, puede que las reglas sean algo complejas para calcular. No sé el estado actual del tema, pero en su tiempo podía depender del servicio dado por el proveedor, de si el servicio abarcaba varias provincias (por ejemplo, un flete que comenzaba en una provincia y terminaba en otra), de lo que nos había facturado en el último mes, de si el proveedor tenía domicilio en una zona de promoción industrial o no, etc. Sea así o no ahora, me sirve como idea de base.

¿Cómo se encararía programar eso con TDD, y base de datos?

Como siempre, paso a paso, “baby steps”. Seguramente atacaríamos primero algunos casos sencillos y luego otros casos más complicados. Cuando se llegue a estos casos (por ejemplo el proveedor con promoción industrial) ponemos en la base de datos bien conocida, un proveedor X que cumpla con lo que necesitamos para el test que estamos desarrollando. Es decir, a medida que resolvemos los test, va quedando en la base (en scripts de creación con datos iniciales) los escenarios que vamos necesitando. Probablemente, un test solamente necesite crear al proveedor (en la etapa de Arrange). Si lo necesitamos a ese proveedor para varios tests, habrá refactor del test para que haya una rutina que lo cree. Pero cuando ya lo necesitamos para varias situaciones, migrará su existencia directamente a la base de datos bien conocida.

Cada desarrollador del equipo, cuando traer el último código del repositorio, podrá ver si alguien modificó los scripts de creación de la base. Y aún si no se da cuenta, al ejecutar los tests de TDD, seguramente alguno quedará en rojo, adviertiendo que algo de base ha cambiado. Toda esta forma de trabajo también sirve cuando en el desarrollo se va cambiando la estructura de la base. Y les sirve para no tener que adoptar mi consejo de modelo en memoria, si aún no se animan a esa forma de trabajo.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD y el juego del Go

lopez — Tue, 22 Jan 2013 16:59:29 GMT

Hace unos años tuve la suerte y el agrado de conocer personalmente a Fernando Aguilar, uno de los mejores jugadores de Go, de Argentina y de Occidente. Pueden leer:

Fernando Aguilar y el Go

Sobre el juego del Go, ver mis posts y links:

http://ajlopez.zoomblog.com/cat/15644
http://delicious.com/ajlopez/go+baduk

Si leen mis posts, ya saben que me interesa la aplicación de la Inteligencia Artificial al juego del Go, ver:

Computer Go y el programa AjGo
AjGo: Hacia un programa que juege al Go

(Nota curiosa: AjGo fue reescrito en 2008 aplicando TDD en cada paso, pueden ver el repo. También pueden vigilar SimpleGo para ir viendo como voy a ir aplicando TDD completo, esta vez en JavaScript).

Pero volvamos al tema. Cuando estuve en la charla de Fernando, le pregunté: cómo piensa la próxima jugada. Quería aprender para poder aplicarlo a mis programas. El go tiene muchas más variantes en cada ply que el ajedrez, y tiene características sutiles, como que una jugada hecha un lugar puede tener grandes efectos en otro lado del tablero. Esto ha impedido que haya programas de go que sean tan avanzados como los que encontramos en ajedrez. Lo que recuerdo de la respuesta:

En determinado momento [cerca de la apertura] no pensé hacia adelante, no me interesó calcular jugadas. Miré el tablero y me dije: Estoy bien. Cualquier cosa que haga el adversario, yo voy a poder contestarle. No tengo debilidades. El futuro no me asusta.

Siempre me quedó esa respuesta (atención, puesta con mis palabras, no tengo las notas que tomé en su momento). También se puede aplicar al ajedrez. No es que no hay situaciones tácticas en go, donde el cálculo de un árbol de jugadas es importante. Pero no se da tanto en la mayoría de los juegos y situaciones, solo por momentos. De ahí que el “approach” Big Blue (atacar con fuerza bruta un gran árbol de búsqueda, con alguna heurística de dónde para en la exploración y evaluaciones parciales) no sea tan aplicable en el caso del go. Hay que trabajar más en buenos algoritmos evaluadores de posiciones estáticas, que me digan “estoy bien”.

Lo mismo nos da TDD, armado con casos de usos, y evitando romper YAGNI. Cualquier cambio que venga (recuerden que en lo ágil abrazamos el cambio, no “luchamos” contra él), cualquier cambio en los requerimientos, cualquier caso de uso nuevo, cuando hago TDD veo que puedo enfrentarlo cuando llegue el caso. No hace falta “pensar jugadas hacia adelante”. Cuando tengo un proyecto armado usando TDD, lo que se va creando crece orgánicamente, sin debilidades grandes. Si alguna vez tenemos que refactorizar en grande, TDD nos da la red de seguridad para enfrentar el cambio con coraje. El aplicar “baby steps” permite que nuestro sistema crezca como un organismo: de a poco. No será un “monstruo” que tenga dos cabezas, o un brazo más grande que otro. Y hasta agregaría que no tendrá cosas insertadas “porque las vamos a necesitar”. No, sólo tendrá lo que habremos necesitado hasta ese punto. Y nuestro código estará preparado para soportar cambios que vengan (que siempre vienen).

Eso nos va a ir dando un sistema que, a cada paso, no tiene mochilas al hombro. Vamos a “estar bien”, y ningún artefacto nos “va a pesar” o nos va a generar fricción. Estaremos en una posición tal como la de Fernando. El sistema y nuestro equipo podrá decir “Estoy bien. No tengo debilidades. El futuro no me asusta” :-)

Bueno, apenas relacionado, pero los otros días veía Enter the Dragon, (1973), la última película de Bruce Lee. Antes de olvidarlo, lo comparto con Uds:

A good fight should be like a small play, but played seriously. A good martial artist does not become tense, but ready. Not thinking, yet not dreaming. Ready for whatever may come. When the opponent expands, I contract. When he contracts, I expand. And when there is an opportunity, I do not hit. It hits all by itself.

Ready for whatever may come.

Dicho esto, que el creador del universo se apiade de los equipos que desarrollan software de producción sin TDD :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Presentando TDD

lopez — Wed, 26 Sep 2012 14:52:00 GMT

Hoy voy a estar dando una charla gratuita sobre TDD, usando Visual Studio, en Buenos Aires, gracias al Microsoft User Group de Argentina. Ya escribí anunciando esta actividad en:

Introducción a TDD con Visual Studio

Así que quiero poner en este post lo que voy a presentar, todo práctico, que será código desarrollado en las dos horas de la charla. Elegiré un dominio y algunos tests, y lo desarrollaremos en el momento. Iré agregando código a mi proyecto de GitHub:

https://github.com/ajlopez/TddOnTheRocks

Seguramente aparecerá hoy un nuevo directorio, con lo que iremos haciendo.

Para los que quieran TDD para una aplicación MVC, hay un video de ALT.NET Hispano:

Desarrollo de una Aplicación con TDD desde 0

explicando el desarrollo de:

https://github.com/ajlopez/TddOnTheRocks/tree/master/TddApp

Un ejemplo más simple:

https://github.com/ajlopez/TddOnTheRocks/tree/master/MySrc

basado en un ejemplo de @hernanwilkinson, explicado en según mi serie de posts:

TDD paso a paso

Dos ejemplos más:

Escribiendo una Aplicación usando TDD
Escribiendo un intérprete en .NET

Recursos adicionales:

Mis posts sobre TDD en español (acá está la lista completa de las series de arriba y algunos post más en otros lenguajes y tecnologías, usando TDD; además, hay algún video demostrativo)
Mis post en Anglish ;-)

Mis enlaces

http://delicious.com/ajlopez/tdd
http://delicious.com/ajlopez/tdd+tutorial
http://delicious.com/ajlopez/tdd+video
http://delicious.com/ajlopez/tdd+codekata

Espero les sirva

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Seminario Gratuito en Buenos Aires: Introducción a TDD con Visual Studio

lopez — Thu, 16 Aug 2012 14:55:20 GMT

Gracias a la gente del MUG de Argentina el día miércoles 26 de septiembre voy a estar dando una charla gratuita sobre uno de mis temas preferidos: Test-Driven Development, usando ejemplo en concreto con C# y Visual Studio. Pueden ver el detalle y registración en:

http://www.mug.org.ar/Eventos/3804.aspx

Fecha y Horario: Miércoles 26 de Septiembre de 2012, en el horario de 18.30 a 20.30 hs.

Vamos a armar desde el comienzo un dominio simple, usando TDD, y el ciclo de: test, rojo, verde, refactor.

Veremos como entonces va “creciendo” nuestro código de manera orgánica, consiguiendo un diseño adecuado a lo que se necesita.
Los tests nos guían en la construcción del software, siendo más que tests, especificaciones, ejemplos de uso esperado del software en construcción.

Y hasta conseguimos ser más productivos y con código mantenible, evitando la sobre-ingeniería, arquitecturas de astronauta, y YAG

Lugar: Auditorio del MUG - Rivadavia 1479, 1er Piso "A" - Ciudad de Buenos Aires

No digan que no les avisé con tiempo :-)

La idea es armar un dominio no básico pero que pueda abarcarse en las dos horas que tenemos dispoibles. Iremos armándolo siguiendo TDD: escribir un test, hacer que funcione en rojo, luego agregar el mínimo código para que pase a verde, y refactor. Esto nos permitirá experimentar algo que no veo muy aplicado por estos lares: la construcción de software paso a paso, con “baby steps”, sin poner todos los patrones “en la parrilla” desde el principio, sino viendo cómo el software en construcción puede verse como un organismo, que se va desarrollando armónicamente, sin grandes saltos ni imponiendo grandes decisiones de antemano. Yo vengo practicando esta forma de programar desde hace años, y me ha dado muchas satisfacciones. Hasta permite dominar la complejidad, justamente, paso a paso. ¿Cómo comerse un elefante? La respuesta ágil es: pedacito a pedacito.

Como comenté en TDD, Tests Unitarios y Mocks, yo soy partidario de la escuela “clásica” de TDD, usando mocks solamente cuando es necesario. Eso es apenas una rama de lo que uno puede adoptar con TDD (y ágil y XP en general): diferir las decisiones (algo escribí sobre el tema en TDD y Casos de Uso). Sobre cómo armar algo que vaya más allá del dominio, por ejemplo, con ASP.NET MVC, lean ese post sobre TDD y casos de uso, y además la charla que quedó en video gracias a la gente de ALT.NET Hispano.

Si no pueden venir a la charla de Buenos Aires, pueden seguir mi serie TDD y Reglas de Negocio, donde encararé un dominio distinto. También tienen varios ejemplos y hasta videos, en mis posts sobre TDD.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD, Test Unitarios y Mocks

lopez — Thu, 09 Aug 2012 15:03:07 GMT

En el mes de Junio pasado dí una charla en lína sobre TDD usando ASP.NET MVC, gracias a la gente de ALT.NET Hispano. Pueden verla aquí. Usé "baby steps”, pasos de bebé, para ir escribiendo el código, usando el ciclo TDD “escribir el test, rojo, verde, refactor”. Tengo otros ejemplos similares, en mis posts sobre TDD de este blog, y en mi cuenta de GitHub. Usualmente, no escribo ni mocks ni stubs. Puedo ser clasificado como un miembro de la escuela “clásica” de TDD, en contraste con la escuela “mockista”. Mi referencia a esta dicotomía (que no tiene que ser tajante) es el artículo de Martin Fowler:

Mocks Aren’t Stubs

Esto es: sólo agrego un mock si REALMENTE lo necesito. Pero alguien podría decir: “Ah! Yo también, sólo los agrego cuando los necesito, pero LOS NECESITO TODO EL TIEMPO”. Yo no pienso de esa manera: los mocks nos son algo imperativo en la programación TDD. El propósito de este post es mostrar que semejante aserción “necesito mocks siempre” es una falacia, que deriva de un entendimiento parcial de lo que es un test, y en especial, un test unitario. Uds. pueden luego decidir usar o no usar mocks y stubs. Pero los mocks sólo son REALMENTE necesarios en TDD en algunas circunstancias (otra historia es la necesidad de mocks en test en general, fuera de TDD, por ejemplo, en “escribo test después del código sólo para tener buen code coverage”).

Leo en ese artículo de Fowler:

xUnit tests follow a typical four phase sequence: setup, exercise, verify, teardown. In this case the setup phase is done partly in the setUp method (setting up the warehouse) and partly in the test method (setting up the order). The call to order.fill is the exercise phase. This is where the object is prodded to do the thing that we want to test. The assert statements are then the verification stage, checking to see if the exercised method carried out its task correctly. In this case there's no explicit teardown phase, the garbage collector does this for us implicitly.

Sí, usualmente escribo el test con una parte de “setup” o “arrange”, que arma el escenario del test. La escual mockista escribiría los mocks (vean el mismo ejemplo en el artículo de Fowler, usando mocks). De ese artículo, se ve que el mismo test, SE PUEDE escribir CON y SIN mocks. Fowler escribe:

The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn't really matter that much.

A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior. In this case for both the warehouse and the mail service.

Veo que todo este tema termina relacionado con lo que llamamos y entendemos por Test Unitario. No hay una clara definición del término: muchos libros de TDD sólo mencionan test, o ponen la expresión “test unitario” de vez en cuando, sin definirla. Voy entonces a la wikipedia:

http://en.wikipedia.org/wiki/Unit_testing

In computer programming, unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use.^[1] Intuitively, one can view a unit as the smallest testable part of an application. In procedural programming a unit could be an entire module but is more commonly an individual function or procedure. In object-oriented programming a unit is often an entire interface, such as a class, but could be an individual method. ^[2] Unit tests are created by programmers or occasionally by white box testersduring the development process.

La parte clave es: un Test Unitario ejercita, prueba, “pone en la fragua” una PARTE del software, usualmente un método individual. En la parte de “act” (dentro de “arrange/act/assert”) pongo un solo comando: la llamada al método que estoy probando, nada más, nada menos.

PERO MUCHA GENTE piensa: esa llamada al método, DEBE INVOLUCRAR SOLO al código de ese método, y no meterse en el código de las otras partes que ese método usa y llama. Bien, eso no es imperativo en TDD. El primer ejemplo de Martin Fowler muestra claramente que se pueden usar otras instancias y métodos. Y esas instancias pueden ser código real de producción, no necesariamente mocks ni stubs. Esa es la escuela clásica de TDD en acción.

Sigo leyendo en la Wikipedia:

Ideally, each test case is independent from the others: substitutes like method stubs, mock objects,^[3] fakes and test harnesses can be used to assist testing a module in isolation.

Acá la clave está en lo de “ideally”. Idealmente para qué? Para poder probar algo de forma aislada, para lograr “isolation”. Pero como toda solución, tiene sus pros y sus contras IMNSHO (In My No So Humbler Opinion :-) perseguir el aislamiento DEBE SER EVALUADO, en términos de costo versus beneficios, NO DEBE SER tomado como un fin en sí. Mi experiencia me muestra, entonces: no vale la pena llegar a eso usando mocks. Usándolos, hay que agregar parvas de código, solamente para conseguir el aislamiento de una prueba unitaria. En cambio, uso otros caminos, como usar código real en el contexto de un escenario que trato de armar de forma ágil. Fowler menciona Object Mother:

In practice, classic testers tend to reuse complex fixtures as much as possible. In the simplest way you do this by putting fixture setup code into the xUnit setup method. More complicated fixtures need to be used by several test classes, so in this case you create special fixture generation classes. I usually call these Object Mothers, based on a naming convention used on an early ThoughtWorks XP project. Using mothers is essential in larger classic testing, but the mothers are additional code that need to be maintained and any changes to the mothers can have significant ripple effects through the tests. There also may be a performance cost in setting up the fixture - although I haven't heard this to be a serious problem when done properly. Most fixture objects are cheap to create, those that aren't are usually doubled.

En mi ejemplo del video que mencioné alprincio, uso algo similar al “object mother” de Fowler, un objeto que prepara el escenario bajo el cual voy a ejecutar mi prueba unitaria. En general, preparo los objetos del dominio, leyéndolos de objetos JSON. Ese “object mother” SOLO APARECE cuando lo comienzo a necesitar en TDD. Recuerden: TDD favorece el uso de YAGNI: no agregar algo que no necesitamos todavía. En muchos proyectos, siguiendo “baby steps”, termino usando un dominio en memoria, con una base de datos/repositorios en memoria. Lean In memory database del mismo Fowler. Un ejemplo de la evolución de mi código siguiendo ese camino (con commits atómicos, casi por tests) en: https://github.com/ajlopez/TddOnTheRocks/tree/master/TddApp. Y en ese ejemplo, comencé programando el controlador, siguiendo un camino “top-down”. Se puede escribir TDD de forma “top-down” o “bottom-up” CON y SIN mocks. El uso de mocks no está relacionado ni con TDD ni con la dirección del armado del código. Algo relacionado y muy interesante referencia es el artículo de @unclebobmartine: No DB:

The center of your application is not the database. Nor is it one or more of the frameworks you may be using. The center of your application are the use cases of your application.

…

What is the best time to determine your data model? When you know what the data entities are, how they are related, and how they are used. When do you know that? When you’ve gotten all the use cases and business rules written and tested. By that time you will have identified all the queries, all the relationships, all the data elements, and you’ll be able to construct a data model that fits nicely into a database.

Does this change if you are using a NoSql database? Of course not! You still focus on getting the use cases working and tested before you even think about the database; no matter what kind of database it ends up being.

Yo pude, varias veces, seguir ese camino, y SIN escribir un SOLO MOCK.

Qué pasa con la pérdida del aislamiento? Por lo menos, en mis proyectos, no ha sido un probelma. Si rompo algo “grande”, puedo tener 40 tests en rojo, pero una rápida inspección me dice que 15 son tests de controladores, 20 en una capa de servicios lógicos y 5 en un repositorio. Entonces, el problema está altamente relacionado con el repositorio. El aislamiento a priori no me fue necesario.

Recientemente, estuve trabajando en un equipo, con gente de diferentes estilos. Algunos no usaban TDD, o sólo escribían "test para aumentar el code ccoverage”. Otros usanban TDD pero había representantes de ambas escuelas, la “clasista combativa” :-) y la mockista. Entonces, cuando había que refactorear una implementación, los test clásicos relacionados con el cambio QUEDABAN en VERDE automáticamente. En cambio, los tests mockistas se rompían, porque estaban muy ligados a lo que se esperaba en la implementación actual o interna. Yo veo ahí que los mocks son una mochila, algo que nos pesa y va en contra del refactor ágil.

¿Cuándo usar, entonces, un mock o un stub? Bueno, esa decisión se las dejo a Uds. Pero quiero mosntrar que es una decisión a tomar en un contexto, no es cuestión de decir “hay que usar mocks siempre, porque eso es TDD”. Realmente, es rara la ocasión en la que tenga que usar un mock en mis proyectos personales. Un ejemplo: puedo tener código que no escribí, un caso: un servicio web externo que tengo que consumir. Entonces, en mis tests, no llamo al servicio web externo (que puede no estar siempre accesible, o tener problemas de latencia). Tampoco un stub. Escribo una implementación que simule el servicio web y LO ENTREGO en la aplicación final de la iteración. No es código sólo para test. Luego, con el tiempo, voy preparando la aplicación para que se pueda configurar, a gusto del consumidor, si quiere usar esa implementación “liviana” o el servicio web real. De esta manera, puedo ir manteniendo el proyecto ágil, y acercarme en cualquier momento a la implementación real.

¿Alguna situación donde usar mocks sea necesario? Hmm.. puede ser en un equipo distribuido, o que tiene repartidas las tareas. El equipo A tiene a su cargo escribir los controladores de una aplicación ASP.NET, y el equipo B tiene que escribir los servicios lógicos, el dominio a consumir. Mientras el equipo B los escribe, el equipo A puede usar mocks de ellos, para tener listos sus controladores. Esa es una situación, en mi opinión, más “legitimada” para usar mocks.

¿Comentarios? ¿Otros pros y contras de las escuelas clásica y mockista?

Podría parafrasear a un político norteamericano del siglo XIX y decir: “El único mock bueno es el mock muerto, el que no se escribe” :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD y Reglas de Negocio (1)

lopez — Sat, 28 Jul 2012 09:47:07 GMT

Este mes estuve trabajando como miembro de un equipo ágil, desarrollando una aplicación privada. Una de las características interesates es que el sistema permite la creación y existencia de entidades del dominio del negecio, aún cuando estén en algún estado “inválido”. El product owner quiere armar un sistema flexible que refleje la realidad del negocio, en vez de uno más estrcito que no permita ese reflejo porque no se cumple alguna regla de negocio. Pero quiere ver también cuáles son las entidades que están en estado “inválido” y por qué. Así que se le muestra (la parte de interfaz de usuario está en ASP.NET MVC) una página con lo que hemos llamado Findings: una lista de mensajes alertando sobre los estados a revisar. Por ejemplo: que tal factura tiene un importe demasiado bajo o que no tiene renglones asociados.

Me gustaría explorar el mode TDD de armar esa característica. Para conseguirlo, necesito un dominio de prueba, y en este post voy a describirlo, simplificado, para tener algo en firme sobre el que implementar los Findings.

Sea una Order. Cada Order tiene uno o más Order Item. Cada Order Item tiene un Product, Quantity, Price (Producto, Cantidad y Precio). Cada Order tiene un Customer (Cliente). Hay reglas de negocio que describen cuáles son los estados “inválidos”. Algunos ejemplos:

- Una Order para un Customer de categoría Y no puede tener un monto total que supere X.
- Una Order debe tener uno o más Order Items.
- Los Order Items deben tener una Cantidad/Quantity > 0.
- Los Order Items deben tener Precio/Price > 0.
- El Producto P debe tener Cantidad > Cantidad Mínima en cada Order Item.
- Producto P tiene un Precio, y cada Order Item que lo incluya no puede tener su Precio < Precio de Producto < 0.80.
- y así…

De esta forma, las Ordenes pueden ser creadas y persistidas sin tener que cumplir con todas las reglas. La Order no es RECHAZADA por el sistema. Solamente que hay páginas para pedir (en cualquier momento) cuáles son los Findings, la lista de las reglas que no se cumplen.

Las reglas de negocio pueden cambiar, y se pueden definir nuevas. No está definido en esta esta etapa del proyecto cómo conseguir esto: puede ser que simplemente agregando código, o escribiendo un DSL (Domain-Specific Languages) de reglas. Por ahora es un tema que no importa. En la aplicación real, el cliente final tiene programadores a disposición, así que la modificación del código sigue siendo una opción aceptable. Bien puede descubrir que 30 reglas bastan, y que no hace falta cambiarlas o se cambian cada 6 meses. Este es un tema a investigar: no siempre crear un DSL de reglas se justifica. En esta versión inicial, las reglas de negocio están en el código, compiladas. En una segunda versión, algunas reglas se aplicarán a algunas órdenes (por ejemplo, a las Orders que tienen clientes de Canadá). El Product Owner quiere tener: Findings por Order, Findings por Producto, Findings por Customer.

En esta serie de post, quiero entonces explorar y mostrar una forma de armar lo pedido, USANDO TDD. Para simplificar el ejemplo, no habrá UI ni persistencia, solamente objetos del dominio, y su grafo de relaciones. Veremos cómo, usando TDD, las reglas y su forma de ejecución van emergiendo desde los casos de uso planteados. Usaré mi cuenta en GitHub para ir compartiendo el código. Será escrito, como la aplicación original, en C#.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD y Casos de Uso

lopez — Wed, 04 Jul 2012 09:44:24 GMT

Ya saben que me importa mucho usar Test-Driven Delopment. Yo diría que es lo primero a adoptar en un desarrollo, como “tecnología nueva”. Pero reconozco que no es fácil a veces transmitir la idea y convencer a la gente de adoptar TDD.

Por ejemplo, hay una idea flotando, que leí hace poco en una lista: “no uso TDD porque el sistema lo tengo que entregar en tres semanas”. Como si TDD fuera algo que alentece. Yo quisiera que se tomara el tiempo, entonces, en cuánto se gasta en la prueba manual o el tiempo que se ocupa usando el “debugger”.

Hace dos semanas, tuve el gusto de dar una charla aplicando TDD desde un “File, New Project”, gracias a la gente de @AltNetHispano (http://altnethispano.org/Inicio.aspx). Lo anuncié en VAN en Alt.NET Hispano: Desarrollando una Aplicación con TDD y pueden ver el resultado en https://github.com/ajlopez/TddOnTheRocks/tree/master/TddApp con commits casi por test. Ese desarrollo fue orientado a terminar en 2 horas, y entonces se mostró cómo por refactor aparecen patrones, para mejorar el código en desarrollo, pero NO APARECEN desde el principio. Al comienzo, TDD brega por el “menor código” que pase el test. Todo mejoramiento de código pasa por refactor. Ese énfasis me hizo dejar algo de lado un tema importante, aunque lo aclaré en la charla: prefiero aplicar TDD escribiendo tests SOBRE CASOS DE USO.

Algo de ese “approach” aparece en la serie de post TDD paso a paso donde se ve cómo se va construyendo el software a partir de un problema planteado por el bueno de @hernanwilkinson. Vean cómo se hace poco diseño de implementación por adelantado: se puede hacer, pero en general con TDD se hace poco o de forma liviana. Los tests nos van guiando qué clases, métodos, estado interno NECESITAMOS debido a que vamos planteando los casos de uso.

En la charla de @AltNetHispano se preguntó: ¿pero qué hacemos si en la primera iteración el cliente/”product owner” nos pide un diagrama de entidad-relación como entregable? Pues bien, respuesta corta: va a ser muy difícil aplicar TDD. Cualquier DER que entreguemos no se basará en casos de uso en concreto, sino que trataremos de “compilar” en nuestra cabeza un modelo POR ADELANTADO de lo que necesitamos. ¿Y eso es problema? No, si NO trabajan ágil y NO usan TDD. ¿Por qué es problema si quieren trabajar ágil y también quieren aplicar TDD? Porque cualquier DER que entreguen será un “dibujo”, algo medio inventado, basado en nuestra capacidad de visualizar qué se necesita SIN HABER planteado un solo caso de uso en concreto. Y hay un problema adicional: ese DER es una “bajada de línea”. En dos semanas más, alguien del equipo comenzará a decir: “no podemos hacer X porque rompemos el DER” y temas parecidos.

Otra bajada de línea aparece con: el “product owner” aparece ya desde el principio con un modelo de datos, de un sistema aún no construido (acepto mejor que venga con una base de datos de un sistema que YA se está usando).

De ahí mi énfasis en usar TDD guiado a su vez por CASOS DE USO. Hace que cada cosa que agregamos (clase, método, estado, entidades, etc…. ) HAGA SU APARICION por haber escrito los tests para un caso de uso. Hace un tiempo me encontré con ideas parecidas de parte de “Uncle Bob” Martin. Les recomiendo lectura de:

No DB

Un párrafo importante:

The center of your application is not the database. Nor is it one or more of the frameworks you may be using. The center of your application are the use cases of your application.

Sigo:

It makes me crazy when I hear a software developer describe his system as a “Tomcat system using Spring and Hibernate using Oracle”. The very wording puts the frameworks and the database at the center.

What do you think the architecture of that system would look like? Do you think you’d find the use cases at the center of the design? Or would you find the source code arranged to fit nicely into the pattern of the frameworks? Would you find business objects that looked suspiciously like database rows? Would the schema and the frameworks pollute everything?

Here’s what an application should look like. The use cases should be the highest level and most visible architectural entities. The use cases are at the center. Always! Databases and frameworks are details! You don’t have to decide upon them up front. You can push them off until later, once you’ve got all the use cases and business rules figured out, written, and tested.

Eso: “una vez que los casos de usos y las reglas de negocio se determinaron/descubrieron, escribieron, y PROBARON”.

A ver, repitan conmigo:

The center of your application are the use cases of your application.

De nuevo, por favor, en serio:

The center of your application are the use cases of your application.

The center of your application are the use cases of your application.

Bien, y ahora, a repetir cada día, frente al espejo:

Databases and frameworks are details!

Si, antes de lavarse los dientes a la mañana repetir:

Databases and frameworks are details!

Databases and frameworks are details!

;-)

Les aseguro que si repiten eso cada día, van a mejorar en sus “skills” de programación, van a mejorar en la calidad del software que engreguen, y van a desarrollar sin tener que pelearse con tecnologías adoptadas por que sí, o porque “era más fácil”.

Recuerden también: “fácil” no es “simple”, y bien puede que lo “fácil” conspire con lo “simple”. Para traer un ejemplo concreto: Rails es “fácil”, permite generar una aplicación web con dos o tres comandos. Ahora, vayan y vean si es “simple” el código.

Les recomiendo leer un “review” de alguna charla de “Uncle Bob” Martin, donde se evalúa lo de más arriba:

The delivery mechanism is an annoying detail

Ahí hay un Tweet de @unclebobmartin

A good architecture allows you to defer framework decisions. A good architecture allows frameworks to act as plugins to the app

Bien, yo diría que las disciplinas ágiles y TDD en particular, permiten también diferir las decisiones. Ese un punto importante. Por ejemplo, en el ejemplo de la charla que mencioné al principio, DIFERI el diseño de la base de datos. Eso permite hacer cambios en las primeras iteraciones, SIN TENER la carga, el peso de la inercia de tener un esquema de tablas, datos cargados, etc.. Pueden ver ese approach en los post:

Escribiendo una aplicación con TDD

Y lean un ejemplo de Ron Jeffries:

http://xprogramming.com/articles/but-we-need-a-database-dont-we/

http://xprogramming.com/articles/see-we-dont-need-a-database-yet/

Si en su equipo todavía hay resistencia a TDD, leer el post de Bob Martin:

http://blog.8thlight.com/uncle-bob/2012/01/11/Flipping-the-Bit.html

En mi charla se mencionó bibliografía. Uno de los libros mencionados fue el

http://www.dirigidoportests.com/el-libro

Les recomiendo leer el ejemplo que los autores describen al principio. Dos programadores, uno usando TDD, y otro trabajando rápido, adoptando frameworks, librerías, todo ya hecho, porque PARECE MAS FACIL, y hasta mejor. Lean el desenlace.

Les puedo comentar un caso, sin dar mucho detalle: en un sistema, había que realizar las tareas A, B, C. Con TDD hubiéramos ido avanzando, tal vez escribiendo un método que invoque a A, B, C, y viendo de revisar, en los tests, los resultados de esas tareas. En vez de eso, se adoptó un “Job Engine”, porque “ya estaba hecho”. Como ese “job engine” funciona dentro de un entorno de tecnología que necesita (usando colas en la nube, monitoreo, etc…), probar que las tareas A, B, C se realicen, es todo un problema. Un año y medio despues, todavía se está analizando por qué algunas tareas se traban en el sitio de producción, o por qué un “job” tarda 15 o más minutos en lanzarse, desde que el pedido se puso en la cola.

Bien, fue un post largo, y espero que haya sido de provecho para alguien. Un resumen:

- Usen TDD guiado por los casos de uso, aceptando lo menos posible “bajadas de línea” sin justificación

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

VAN en Alt.NET Hispano: Desarrollando una Aplicación con TDD

lopez — Mon, 18 Jun 2012 16:29:07 GMT

El sábado que viene, 23 de Junio, estaré en una VAN (reunión virtual) organizada por el grupo Alt.NET Hispano, tratando el tema de cómo desarrollar una aplicación con TDD. El horario es el habitual 18pm GMT, en Buenos Aires tenemos GMT-3, y es 3 de la tarde hora local.

Quiero mostrar cómo uso habitualmente TDD para ir desarrollando una aplicación. Usaré C#, una interfaz con ASP.NET MVC, y seguramente algún proyecto de clases donde ir poniendo el dominio. Estoy pensando más en detalle el dominio, quisiera uno que pudiera abarcar en las dos horas que tenemos disponibles, y que tuviera algunas reglas.

Para mí, es muy importante usar TDD en código en producción. Me ha resultado muy útil, no sólo por la cobertura de tests que me permite refactorizar con confianza, sino por el proceso de diseño del código y de la aplicación en sí. En los últimos años le he agregado también la idea de que lo importante son los casos de uso, y darle menos peso a temas como el diseño de la base de datos que puede aparecer más adelante en un desarrollo ágil, no tiene por qué estar desde el principio.

Ya escribí varios posts sobre desarrollo con TDD y mis proyectos personales públicos prácticamente están todos desarrollados con TDD (pueder ver mi cuenta de GitHub cómo van avanzando test a test). Pero no había tenido la oportunidad de mostrar esta técnica en una VAN sobre una aplicación y un dominio. Espero que pueda mostrar qué bueno es aplicar TDD desde el comienzo, y cómo nos ayuda en un desarrollo ágil.

Más información sobre Alt.NET Hispano en:

http://altnethispano.org/Inicio.aspx

Sobre las reuniones VAN y cómo participar en:

http://altnethispano.org/reuniones/descripcion.aspx

Las anteriores VAN han sido publicadas (en video) en:

http://altnethispano.org/reuniones/historico.aspx

El calendario de próximo eventos en:

http://altnethispano.org/reuniones/calendario.aspx

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD Paso a Paso (6) La semana del panadero

lopez — Fri, 25 May 2012 22:36:09 GMT

Anterior Post

Sigamos mejorando la clase de calendario de días laborables. Quiero ahora plantear el caso:

- El sábado y domingo se trabaja
- El lunes no se trabaja

Acá en Argentina, es común que así sea la semana del panadero (aunque dado los tiempos que corren, muchos abren todos los días). Este es el test que me armé: configuro al calendario con sábado y domingo como días laborales, y lunes como no laborable. Luego se prueban esos tres días:

[TestMethod]
public void SetWeekendAsWorkingDaysAndMondayAsANonWorkingDay()
{
	WorkingDaysCalendar calendar = new WorkingDaysCalendar();

	calendar.AddDayOfWeekAsWorkingDay(DayOfWeek.Saturday);
	calendar.AddDayOfWeekAsWorkingDay(DayOfWeek.Sunday);
	calendar.AddDayOfWeekAsNonWorkingDay(DayOfWeek.Monday);

	DateTime saturday = new DateTime(2012, 3, 10);
	Assert.AreEqual(saturday.DayOfWeek, DayOfWeek.Saturday);

	Assert.IsTrue(calendar.IsWorkingDay(saturday));
	Assert.IsTrue(calendar.IsWorkingDay(saturday.AddDays(1)));
	Assert.IsFalse(calendar.IsWorkingDay(saturday.AddDays(2)));
}

Al ejecutar este código, si tenemos la clase calendario del post anterior, da en rojo, porque no tengo contemplado más que un día especial por tipo: sólo un día laborable especial, o sólo un día no laborable especial. Pero al llegar a este test, puedo implementar mejor el algoritmo interno. Llegó la hora de tener una lista de días:

public class WorkingDaysCalendar
{
	private IList<DayOfWeek> nonWorkingDaysOfWeek = new List<DayOfWeek>() { DayOfWeek.Saturday, DayOfWeek.Sunday };

	public bool IsWorkingDay(DateTime day)
	{
		if (this.nonWorkingDaysOfWeek.Contains(day.DayOfWeek))
			return false;

		return true;
	}

	public void AddDayOfWeekAsWorkingDay(DayOfWeek dayOfWeek)
	{
		if (this.nonWorkingDaysOfWeek.Contains(dayOfWeek))
			this.nonWorkingDaysOfWeek.Remove(dayOfWeek);
	}

	public void AddDayOfWeekAsNonWorkingDay(DayOfWeek dayOfWeek)
	{
		if (!this.nonWorkingDaysOfWeek.Contains(dayOfWeek))
			this.nonWorkingDaysOfWeek.Add(dayOfWeek);
	}
}

Agregué una lista interna de días no laborables, sin cambiar la interfaz pública de la clase. ¿Pero habré cumplido con lo pedido con el test? Ejecuto, y da verde. ¿Pero no habré roto algo? Ejecuto el resto de los tests, también estan en verde. En cualquier caso, seguiría trabajando hasta que todo quede en verde. Luego, vendría refactorización. Por ejemplo, no estoy conforme conque los métodos comienzen con Add. No se agregan días, sólo se informa de su carácter de laborable o no laborable. Pero bueno, eso será para otro post.

Próximos temas: refactorizar, soporte de días feriados, feriados puentes, etc…

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD Paso a Paso (5) Lunes como día no laborable

lopez — Wed, 09 May 2012 09:11:00 GMT

Anterior post
Siguiente post

Veamos ahora otro test, que como los anteriores, nos va a obligar a implementar mejor nuestro software en construcción.

Queremos configurar, sobre la semana básica, cuáles son los días laborables y cuáles son no laborables. En el anterior post, agregué la capacidad de especificar un nuevo día laboral. Ahora, quiero poder especificar que los lunes son no laborables. Este es el test que escribí:

[TestMethod]
public void SetMondayAsANonWorkingDay()
{
	WorkingDaysCalendar calendar = new WorkingDaysCalendar();

	calendar.AddDayOfWeekAsNonWorkingDay(DayOfWeek.Monday);

	DateTime monday = new DateTime(2012, 3, 12);
	Assert.AreEqual(monday.DayOfWeek, DayOfWeek.Monday);

	Assert.IsFalse(calendar.IsWorkingDay(monday));
}

Primero, no compila. Porque usa el método no existente, AddDayOfWeekAsNonWorkingDay . Lo creo, lanzando una excepción de no implementado, ejecuto el test, y da rojo. Pongamos el mínimo código que hace que esto funcione, con algún refactor de nombre de parámetros.

private DayOfWeek? workingDay;
private DayOfWeek? nonWorkingDay;

public bool IsWorkingDay(DateTime day)
{
	if (this.workingDay.HasValue && this.workingDay.Value == day.DayOfWeek)
		return true;

	if (this.nonWorkingDay.HasValue && this.nonWorkingDay.Value == day.DayOfWeek)
		return false;

	if (day.DayOfWeek == DayOfWeek.Sunday || day.DayOfWeek == DayOfWeek.Saturday)
		return false;

	return true;
}

public void AddDayOfWeekAsWorkingDay(DayOfWeek dayOfWeek)
{
	this.workingDay = dayOfWeek;
}

public void AddDayOfWeekAsNonWorkingDay(DayOfWeek dayOfWeek)
{
	this.nonWorkingDay = dayOfWeek;
}

Ahora el test está en verde. Agregué una nueva variable interna “nullable” nonWorkingDay. Ciertamente que la clase escrita sólo soporta un sólo día laborable configurable y un sólo día no laborable configurable. Pero los tests que escribimos pasan. Voy por “baby steps”, de a “pasos de bebé”.

Pero van viendo la aplicación de TDD: en cada test, hay una nueva especificación de cómo queremos que actúe nuestro software en construcción. Y sólo implementamos lo que necesitamos para pasar el test. Poco a poco, va emergiendo la implementación interna, donde ponemos lo que conocemos como programadores. Pero sin caer en la tentanción de “Ah! acá pongo esto que lo voy a necesitar”. Si el test no lo necesita, nosotros tampoco :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez