Angel "Java" Lopez : TDD, C Sharp

Mass Lenguaje de Programación (4) Lexer y Parser

lopez — Sun, 12 May 2013 08:40:21 GMT

En la implementación del lenguaje Mass, tengo una enumeración y una clase:

Un Token representa una palabra del código a procesar. El encargado de separar el código en palabras es el Lexer. Y con el Parser se transforma esa corriente de Tokens en expresiones y comandos:

El constructor de Lexer recibe un string:

public Lexer(string text)
{
    this.text = text;
}

Y ese string es procesado para separarlo en tokens. Vean que el Lexer distingue entre operadores (como +) y separadores (como los paréntesis). También toma en cuenta al fin de línea como token (en otros lenguajes, como C, un fin de línea se puede tomar como un espacio en blanco en muchas situaciones). El principal método de Lexer es NextToken, que devuelve el próximo Token del texto. En algunas pocas situaciones, se hace necesario devolver el Token consumido, y para eso está PushToken y varianes.

El Parser interamente maneja un Lexer. Le podemos pedir el próximo comando con ParseCommand, y la próxima expresión con ParseExpression. Cuando el texto en proceso se acaba, esos métodos devuelven null.

Voy a modificar el Lexer para consumir un stream de texto, para poder procesar, por ejemplo, entrada de consola

Tengo que seguir pensando si internamente, unifico comandos y expresiones, como pasa en Ruby, donde cada “comando” tiene un valor (en Mass también es así), y no solamente eso, sino que puede ser usado como expresión en el contexto de un comando.

Nos leemos!

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

Mass Lenguaje de Programación (3) Comandos

lopez — Sun, 28 Apr 2013 11:24:00 GMT

Anterior Post
Siguiente Post

Veamos hoy cómo están implementados los comandos en Mass (ver repo). En el proyecto de librería de clases, tengo:

Hay comandos para if, while, for, for each, etc…. Todos implementan la interfaz ICommand:

public interface ICommand
{
    object Execute(Context context);
}

Vean que es muy parecido a IExpression. Igual quise mantener comandos y expresiones por separado, por lo menos en esta primera implementación, para tener un claro delineamiento de los conceptos de base del lenguaje.

Un ejemplo típico de comando es el WhileCommand (parte del código):

public class WhileCommand : ICommand
{
    private static int hashcode = typeof(WhileCommand).GetHashCode();

    private IExpression condition;
    private ICommand command;

    public WhileCommand(IExpression condition, ICommand command)
    {
        this.condition = condition;
        this.command = command;
    }

    public object Execute(Context context)
    {
        for (object value = this.condition.Evaluate(context); 
            value != null && !false.Equals(value);
            value = this.condition.Evaluate(context))
        {
            this.command.Execute(context);
            if (context.HasContinue())
                context.ClearContinue();
            if (context.HasBreak())
            {
                context.ClearBreak();
                break;
            }
        }

        return null;
    }
}

Para Mass: cualquier valor null o false es falso. Todo lo demás es verdadero. Un tema a refactorizar: poner un método IsFalse para se usado tanto en la implementación de While como de If.

Otro ejemplo es el ForEachCommand (parte del código):

public class ForEachCommand : ICommand
{
    private string name;
    private IExpression expression;
    private ICommand command;

    public ForEachCommand(string name, IExpression expression, ICommand command)
    {
        this.name = name;
        this.expression = expression;
        this.command = command;
    }

    public object Execute(Context context)
    {
        var values = (IEnumerable)this.expression.Evaluate(context);

        foreach (var value in values)
        {
            context.Set(this.name, value);
            this.command.Execute(context);
            if (context.HasContinue())
                context.ClearContinue();
            if (context.HasBreak())
            {
                context.ClearBreak();
                break;
            }
        }

        return null;
    }
}

Vean que para Mass, todo lo que sea IEnumerable se puede usar para ser consumido por este comando. Tuve que poner algunos datos en el contexto, para saber si se había hecho un break o un continue.

Y como siempre, todo esto desarrollado con TDD: pueden ver los commits del repo.

Próximos posts: Lexer y Parser, ejemplos de Mass para scripting.

Nos leemos!

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

Mass Lenguaje de Programación (2) Primeras Expresiones

lopez — Sat, 27 Apr 2013 13:26:00 GMT

Anterior Post
Siguiente Post

Antes de ver cómo usar el lenguaje Mass (ver repo), quisiera tratar algunos temas de implementación. Primero, una novedad: ahora hay una solución (en https://github.com/ajlopez/Mass/blob/master/Src/Mass.sln) que puede compilarse con algún Visual Studio C# Express, de libre bajada e instalación.

La solución Mass tiene un proyecto de librería de clases. Ahí hay un namespace dedicado a expresiones:

Una expresión es algo que cumple con IExpression:

  
public interface IExpression
{
	object Evaluate(Context context);
}

Un Context mantiene un diccionario de nombre/valor, para guardar las variables actuales:

  
public void Set(string name, object value)
{
	this.values[name] = value;
}

public object Get(string name)
{
	if (this.values.ContainsKey(name))
		return this.values[name];

	if (this.parent != null)
		return this.parent.Get(name);

	return null;
}

(vean de refilón, que soporta contextos anidados: cada contexto puede “heredar” de un contexto parent).

La expresión más simple es la que devuelve una constante, que puede ser cualquier valor/objecto .NET:

  
public class ConstantExpression : IExpression
{
	// ...

	private object value;

	public ConstantExpression(object value)
	{
		this.value = value;
	}

	public object Evaluate(Context context)
	{
		return this.value;
	}

	// ...
}

La siguiente expresión más simple es la evaluación de un nombre de variable en el contexto actual:

  
public class NameExpression : IExpression
{
	// ...
	
	private string name;

	public NameExpression(string name)
	{
		this.name = name;
	}

	public object Evaluate(Context context)
	{
		return context.Get(this.name);
	}
	
	// ...
}

Es necesario especificar el contexto (por ejemplo, el contexto de la función actual, de una clausura, del objeto actual, del módulo actual, etc), porque un mismo nombre puede tener distintas variables asociadas, como pasa en otros lenguajes.

Como siempre, cada una de estas clases (Expresiones, Contexto, …) fue armada usando el flujo de trabajo de TDD (ver el proyecto de tests, y la historia de commits del repo donde dejé evidencia de cómo fue el desarrollo en el tiempo).

Próximos posts: algunas expresiones adicionales, comandos, usando Mass para scripting, usando Mass desde nuestro programa .NET, etc..

Nos leemos!

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

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

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

Anterior Post

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

Mass Lenguaje de Programación (1) Orígenes

lopez — Mon, 08 Apr 2013 10:43:00 GMT

Siguiente Post

Durante estos días, estuve trabajando en la implementación de un lenguaje interpretado, sobre C#, llamado Mass (dedicado al bueno de @MArtinSaliaS):

https://github.com/ajlopez/Mass

La solución actual se compone de tres proyectos: una librería de clases, sus tests, y un programa de consola, mass.exe, para lanzar programas Mass

Pueden lanzar un programa escrito en un archivo hello.ms con

mass hello.ms

El clásico Hello world es entonces

println("Hello, world")

Un ejemplo con clases y objetos

class Person
	define initialize(firstname, lastname)
		self.firstname = firstname
		self.lastname = lastname
	end
	
	define getName()
		return self.lastname + ", " + self.firstname
	end
end

adam = new Person("Adam", "TheFirst")

println(adam.getName())

Un ejemplo con acceso a tipos y objectos .NET:

dirinfo = new System.IO.DirectoryInfo(".")

for fileinfo in dirinfo.GetFiles()
	println(fileinfo.Name)
end

La idea es (como en AjSharp y otras implementaciones) tener un lenguaje dinámico montado sobre un lenguaje/librería de clases. Y poder acceder a esa librería de clases desde el nuevo lenguaje. Me llevó a escribir Mass de la forma en que lo hice, el haber trabajado antes en:

- Implementar Python en C# (ver PythonSharp)

- Implementar Ruby en C# (ver RubySharp)

- El ya mencionado AjSharp (ver repo y posts)

Pero esta vez quería implementar algo que tuviera sintaxis y semántica simple. Ya estuve pensando en eso de “simple” para implementar un compilador de lenguaje simple a JavaScript ver SimpleScript

Entonces con Mass me propuse evitar:

- Múltiples comandos en la misma línea (descarté el ‘;’ de Ruby)

- Sintaxis basada en espacios en blanco, indentación (descartado Python)

- Llamadas a funciones con simplemente el nombre: se necesita explícitamente los paréntesis (descartado el Ruby clásico)

- Que las clases/valores de base (por ejemplo, enteros, strings, arreglos, etc…) tuvieran multitud de métodos (tienen los dados por la librería de clases de implementación, en este caso .NET) (descartado Ruby, que tiene casi tantos métodos nativos como PHP)

Y quise tener:

- Valores funcionales, como ciudadanos de primera clase, como en JavaScript. Vean que al tener que invocar una función con paréntesis, si o si, entonces la variable func tiene el valor funcional, y func() es la invocación explícita

- Objectos dinámicos: cada objeto puede extenderse en cualquier momento, con nuevas variables de instancia, funciones propias del objeto, como JavaScript

- Sintaxis basada en líneas: cada comando va en una línea distinta

- Sintaxis basada en palabras claves: para los comandos compuestos se usa ‘end’ para terminar un bloque

- En lo posible, una sola forma de hacer algo, en vez de múltiples maneras

- Palabras claves completas, ‘define’ en vez de ‘def’

- Clases con herencia simple (aunque la esencia de Mass bien puede expresarse sin clases, y usar librerías de clases ya escritas en .NET)

- Modificación explícita de variables fuera del alcance local (para explicar en próximos posts)

- Alcance de variables por archivo, como en JavaScript/NodeJs/CommonJS

- Módulos por archivo, con un require que permite buscar en directorios automáticamente, como en NodeJs/CommonJS

- Empaquetamiento, manejo de dependencias e instalación de esos módulos usando algo ya dado, como NPM, el manejador de paquetes de Node.js

En próximos posts, más detalles de implementación, ideas que guiaron el diseño, ejemplos. Pero ya pueden ver el código, y los ejemplos que están en los tests (sí, está todo construido paso a paso usando TDD).

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

Escribiendo un Intérprete en .NET (Parte 10)

lopez — Mon, 18 Mar 2013 09:50:56 GMT

Anteriores posts de la serie:

Escribiendo un Intérprete en .NET (Parte 9)
Escribiendo un Intérprete en .NET (Parte 8)
Escribiendo un Intérprete en .NET (Parte 7)
Escribiendo un Intérprete en .NET (Parte 6)
Escribiendo un Intérprete en .NET (Parte 5)
Escribiendo un Intérprete en .NET (Parte 4)
Escribiendo un Intérprete en .NET (Parte 3)
Escribiendo un Intérprete en .NET (Parte 2)
Escribiendo un Intérprete en .NET (Parte 1)

Hace unos meses que no escribo en esta serie, pero es porque he directamente escrito varios intérpretes, usando TDD, y haciendo “commits” prácticamente por tests en mi cuenta de GitHub, siguiendo las ideas de esos posts.

Intérpretes que estoy escribiendo, parecidos al descripto en los posts, son:

PythonSharp (ver los commits) (lo presenté en la PyCon Argentina 2012)

RubySharp (ver los commits)

Y para un ejemplo de un lenguaje diferente, vean una implementación de Clojure que estoy escribiendo en C#:

ClojSharp

Por ejemplo, hoy escribi un nuevo verbo de ClojSharp, la que se llama “let special form”, tienen los commits por tests de hoy:

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

Pueden ver uno en:

https://github.com/ajlopez/ClojSharp/commit/51c678ece96d6d1cef92f36afda8d8fc711ffd8c

donde GitHub nos muestra los cambios en el código.

Otro ejemplo, lo que hice ayer, test por test, en RubySharp:

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

Espero que estos ejemplos les sirvan para ir viendo cómo se puede usar TDD para este tipo de proyectos. Tengo más ejemplos de otros tipos de aplicaciones en mis posts de TDD.

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

TDD Paso a Paso (4) Otro tipo de Semana

lopez — Tue, 24 Apr 2012 10:05:00 GMT

Anterior Post
Siguiente Post

Ahora veamos de tratar uno de los requerimientos: que los días laborables/no laborables sean configurables, ya sea por feriados puntuales, feriados que se repiten año a año, o porque la propia semana tenga otro reparto de días laborables.

El primero que se me ocurre es contemplar que el sábado sea día laboral. Escribo el test:

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

	calendar.AddDayOfWeekAsWorkingDay(DayOfWeek.Saturday);

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

	Assert.IsTrue(calendar.IsWorkingDay(saturday));
}

Al ejecutarlo, da rojo, porque el código que tengo hasta ahora pone a los sábados como días no laborables. Siguiendo la idea de poner el mínimo código necesario para pasar el test, y que sigan dando verde los anteriores, éste es el código que agregué (y luego refactoricé un poco):

private DayOfWeek? workingDay;

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

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

	return true;
}

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

Con esto, el test da en verde. Ejecuto toda la batería de test y sigue dando verde.

Noten que la variable adicional es “nulleable”. Podría haber puesto un arreglo, una lista de días laborables o algo así. PERO NINGUN TEST ME LO PIDIO. Es decir, no hay caso de uso del código que estamos desarrollando que necesite esa flexibilidad. Seguramente en los próximos test tendré que agregarlo. Pero no cruzar el puente ANTES de llegar al puente.

Nos leemos!

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

TDD Paso a Paso (3) Domingo y Semana Típica

lopez — Wed, 18 Apr 2012 14:25:00 GMT

Anterior Post
Siguiente Post

Sigo con la descripción de los tests que fui escribiendo para este problema. Ahora que ya tengo un test para ver si sábado es día laborable, agregué un test para ver si cada domingo es día laborable:

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

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

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

Inicialmente, el test quedó en rojo. El problema es que el código que llevo escrito solamente reconoce como no laborable a los Sábados. Modifiqué la función que determina eso a:

public bool IsWorkingDay(DateTime day)
{
    if (day.DayOfWeek == DayOfWeek.Sunday || day.DayOfWeek == DayOfWeek.Saturday)
        return false;

    return true;
}

Y el test pasó. Vean que aparecen dos constantes en el código interno. No me preocupa por ahora, porque refleja lo que tengo hasta ahora en los tests. En algún momento, tendré que contemplar (como pedía el problema original) que hay otras semanas típicas: por ejemplo, para un peluquero el sábado puede ser día laborable, y para una panadería el domingo es laborable pero el lunes no.

Llegado a este punto, escribí un test que sale un poco de TDD “estricto”. Es un tests que me dió en verde desde el comienzo. Es el que prueba los días de una semana típica:

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

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

    Assert.IsTrue(calendar.IsWorkingDay(monday));
    Assert.IsTrue(calendar.IsWorkingDay(monday.AddDays(1)));
    Assert.IsTrue(calendar.IsWorkingDay(monday.AddDays(2)));
    Assert.IsTrue(calendar.IsWorkingDay(monday.AddDays(3)));
    Assert.IsTrue(calendar.IsWorkingDay(monday.AddDays(4)));
    Assert.IsFalse(calendar.IsWorkingDay(monday.AddDays(5)));
    Assert.IsFalse(calendar.IsWorkingDay(monday.AddDays(6)));
}

Me gusta tener ese test, para que alguien pueda ver, en un solo lugar, lo que considero para esta API como semana típica. Otros “approach”: no escribir este test, o escribirlo y eliminar los anteriores. Pero yo me “encariño” :-) con los tests, y es raro que los elimine. También dan una idea de la historia, de la evolución de la API. Así que agregué este test de arriba, nacido prístinamente en verde, y dejé los anteriores.

Próximos posts: cómo admitir otro tipo de semanas “típicas”, feriados, etc.

Como siempre, toda esta serie de cambios quedó reflejado en el log del proyecto. Ver https://github.com/ajlopez/TddOnTheRocks

Nos leemos!

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

TDD Paso a Paso (2) Días No Laborables

lopez — Tue, 20 Mar 2012 16:20:00 GMT

Anterior Post
Siguiente Post

En el primer post de esta serie, expliqué el problema y el primer test, que va quedando en el repositorio del proyecto.

Veamos ahora el segundo test. Me decidí por probar que un domingo típico es día no laborable, que implica un cambio con respecto al anterior test. En el primer test que escribimos, preguntábamos por un caso positivo de día laborable. Ahora cambiamos a probar un caso negativo.

El nuevo test:

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

    DateTime sunday = new DateTime(2012, 3, 11);
    Assert.AreEqual(sunday.DayOfWeek, DayOfWeek.Sunday);

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

Al ejecutarlo, da rojo. El problema es que la actual implementación retorna que todos los días de la semana son laborables. El mínimo cambio en el código que hace que todo funcione es:

public bool IsWorkingDay(DateTime day)
{
    if (day.DayOfWeek == DayOfWeek.Sunday)
        return false;

    return true;
}

Ahora sí funciona, habiendo agregado el if del comienzo. El próximo test que se me ocurre es probar que un sábado típico (más adelante veremos otros calendarios, por ejemplo, el de un peluquero, que acá en Argentina tienen como día no laborable el lunes, y muchos trabajan el sábado Y el domingo; era parte de los requerimientos, poder configurar el calendario). El tercer test, entonces, es:

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

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

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

Mínimo código que hace que el test pase a verde:

public bool IsWorkingDay(DateTime day)
{
    if (day.DayOfWeek == DayOfWeek.Sunday || day.DayOfWeek == DayOfWeek.Saturday)
        return false;

    return true;
}

Agregué un día más no laborable en la condición del if.

Vean que quedaron dos constantes el código de implementación. Por ahora, no me preocupa. Es más: me parece que son constantes que reflejan algo básico del sistema que estamos armando, no son constantes arbitrarias. Comienza a surgir lo que entiendo como calendario típico: semana laborable, excepto sábados y domingo.

No hice mucho refactoring en estos test. Diferencias con el Coding Dojo: sigo usando nombres significativos para los tests (si hay que cambiarlos, los cambio). Tampoco usé métodos auxiliares que me devuelvan un lunes o un domingo o un sábado. Si necesito esos métodos, será porque surjan de refactor de código de tests (probablemente, si necesito obtener un lunes desde más de 2 tests, digamos).

Próximos pasos: ver qué es una semana típica, plasmarla en un test; comenzar a configurar el calendario (tal vez, sábado es laborable, para algunas profesiones, que usaran un calendario configurable para ellas).

Nos leemos!

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

TDD Paso a Paso (1) Primer Test

lopez — Sun, 18 Mar 2012 16:15:00 GMT

Siguiente Post

Comenté en el post Coding Dojo – TDD on the Rocks el ejercicio que hicimos en conjunto con el bueno de @HernanWilkinson. Quisiera hoy comenzar una serie explicando un poco mi estilo de programar ese ejercicio, para ir viendo las diferencias con lo visto en el coding dojo. No digo que sea mejor o peor, pero sí que es la forma en la que me siento más cómodo. Esta forma de encarar TDD (Test-Driven Development) la estoy publicando en

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

Pueden ver ahí el log de lo que fui escribiendo: estuve enviando commit al repositorio Git prácticamente por cada paso. Les recuerdo el problema:

- Calendario de días laborables y no laborables

- Se debe saber si una fecha particular es laborable o no

- Se debe configurar con:

- día de la semana no laboral (ej. Domingo)

- día de mes no laboral (ej. Primero de Enero)

- fecha particular no laboral (ej. 4 de Abril de 2012)

Primero, construí una solución en C# con Visual Studio, con dos proyectos: uno de librería de clases, y otro de test:

Vean que fui creando una clase para los tests, y otra clase para lo que quieron implementar. Ahí difiero del “approach” de @HernanWilkinson, que llamó a la clase de tests con un nombre no significativo. Yo prefiero empezar con un nombre más relacionado con el problema, aunque puede que después lo cambie.

El primer tests, para mí, es probar que los lunes, en general, son un día laborable. Este fue mi primer test:

[TestMethod]
public void TypicalMondayIsAWorkingDay()
{
	WorkingDaysCalendar calendar = new WorkingDaysCalendar();
	
	DateTime monday = new DateTime(2012, 3, 12);

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

Acá otra “departure” del ejercicio del coding dojo. Mientras que aquel día codificamos el test poniéndole un nombre neutro como test1, yo prefiero darle un nombre significativo desde el principio, aunque después lo cambie. Me queda claro qué estoy intentando hacer, y también para cualquiera que lo vea. No me ha pasado con frecuencia que tenga que cambiar radicalmente el nombre a un test. Pueden ver los logs de proyectos de código abierto (por ejemplo los de GitHub), para notar que no he necesitado mucho el “renaming” de nombre de test.

Pero este test no compila. Armé una primera clase:

public class WorkingDaysCalendar
{
	public bool IsWorkingDay(DateTime day)
	{
		throw new NotImplementedException();
	}
}

que consigue que el test compile, pero al ejecutarlo, da rojo. El código mínimo que consiguió que pase a verde:

public bool IsWorkingDay(DateTime day)
{
	return true;
}

No hay mucho lugar para hacer refactor, en este punto. Pero mejoré el código de test, para afirmar/controlar explícitamente que la fecha que estoy usando es un lunes:

[TestMethod]
public void TypicalMondayIsAWorkingDay()
{
	WorkingDaysCalendar calendar = new WorkingDaysCalendar();
	
	DateTime monday = new DateTime(2012, 3, 12);
	Assert.AreEqual(monday.DayOfWeek, DayOfWeek.Monday);

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

En el coding dojo usamos una función someSunday() (en este caso sería someMonday()), pero todavía no la necesité. Así que para mantener el test simple, me bastó crear una fecha de lunes directamente en el código del test. Para cualquiera que lea el test dentro de un año, me aseguro que la fecha elegida sea la de un lunes.

En el próximo post comentaré los siguientes tests que se me ocurrieron: probar que un domingo típico es no laborable, y que un sábado típico tampoco. Veremos cómo fue emergiendo la implementación interna, y al llegar a nuevos tests, cómo esta implementación fue siendo mejorada y refactorizada.

Jeje… “dog fooding”, el código de arriba fue “coloreado” con Acquarella.

Nos leemos!

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

Escribiendo una Aplicación usando TDD (Part 5) Agregando Vistas

lopez — Mon, 27 Jun 2011 10:21:00 GMT

Anterior Post
Próximo Post

Ahora ya tengo algunos tests y en verde. Voy a agregar algunas vistas MVC en este paso de hoy. Pueden bajar el código desde mi AjCodeKatas Google Project, en trunk/AppTdd/Step04. Así que este post tiene pocos nuevos tests: muestra que podemos agregar interfaz de usuario DESPUES de los tests, y (para destacar) SIN TENER una base de datos aún, ni siquiera una capa de servicios (“service layer”).

Primero, agregué una master page Site.master y un estilo style.css (que tomé de otro proyecto ASP.NET MVC 2)

Agregué un nuevo controlador Home:

Y usando el menú de contexto sobre el método Index agregué una vista asociada al método:

Modifiqué el código de la master page para tener una nueva opción en el menú:

Entonces, agregué una vista, esta vez asociada al método Index del controlador Subject:

Seleccioné a “List” como “Vien Content”, y a “Subject” como el tipo a usar como base del modelo.

Pero el método del controlador es:

public ActionResult Index()
{
    return View(subjects);
}

Usa una lista de temas (“subjects”) que ha sido inyectada hasta ahora en un constructor por los tests:

public SubjectController(IList<Subject> subjects)
{
    this.subjects = subjects;
}

Pero esperen! Esa lista es inyectada por los tests. Ahora, necesito que esté disponible en el proceso normal de un controlador. Así que agregué un constructor sin parámetros:

public SubjectController()
    : this(Domain.Instance.Subjects)
{
}

El Domain.Instance es un dominio en memoria:

public class Domain
{
    private static Domain instance = new Domain();
    private Domain()
    {
        this.Subjects = new List<Subject>()
        {
            new Subject() { Id = 1, Name = "Mathematics" },
            new Subject() { Id = 2, Name = "Physics" },
            new Subject() { Id = 3, Name = "Biology" },
            new Subject() { Id = 4, Name = "Literature" }
        };
    }
    public static Domain Instance { get { return instance; } }
    public IList<Subject> Subjects { get; set; }
}

Ahora sí el controlador de Subject puede manejar el método Index. Cambio enlaces en la vista que me agregó el wizard. Los cambio de:

a que usen la propiedad Id como clave primaria:

Este es el resultado:

Creé entonces otras vistas, para los otros métodos del controlador Subject. Seguí usando el wizard de Visual Studio “Add View … “:

Me encontré que me faltaban algunas acciones. Escribí una nueva:

public ActionResult Edit(int id)
{
    var model = this.subjects.Where(s => s.Id == id).FirstOrDefault();
    return View(model);
}

con tests! ;-)

[TestMethod]
public void GetSubjectForEdit()
{
    IList<Subject> subjects = GetSubjects();
    SubjectController controller = new SubjectController(subjects);
    ActionResult result = controller.Edit(1);
    Assert.IsNotNull(result);
    Assert.IsInstanceOfType(result, typeof(ViewResult));
    ViewResult viewResult = (ViewResult)result;
    Assert.IsInstanceOfType(viewResult.ViewData.Model, typeof(Subject));
    Subject model = (Subject)viewResult.ViewData.Model;
    Assert.AreEqual(1, model.Id);
    Assert.AreEqual("Mathematics", model.Name);
}

Curiosamente, detecté un test “malo”. Yo había escrito en test AddSubject:

Assert.IsTrue(subjects.Any(s => s.Name == "Chemistry"));
Assert.AreEqual(4, subject.Id);

Pero el nuevo Id debería dar 5 (mi lista usada en los tests tiene 4 temas predefinidos (“subjects”)):

Assert.IsTrue(subjects.Any(s => s.Name == "Chemistry"));
Assert.AreEqual(5, subject.Id);

Arreglé el código y la acción del controler, ejecuté la aplicación web, y voila! Todo funcionó.

Puntos principales:

- Estoy usando un dominio en memoria.

- Las vistas se ejecutan sobre las acciones YA probadas con tests

No hay capa lógica de servicios ni persistencia, aún. Vean que no son necesarias al principio. Voy a agregar una “service layer” como gran refactor. Otros próximos pasos: agregar más clases al dominio (libros en clase Book), escribir esa capa de servicio usando tests, “enchufarla” en los controladores. Y en algún momento agregar persistencia.

Pueden leer posts interesantes sobre TDD sin una base de datos (o agregándola después) escritos por @RonJeffries:

But We Need a Database … Don’t We? | xProgramming.com
See? We Don’t Need a Database … Yet | xProgramming.com

Nos leemos!

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

Escribiendo una Aplicación usando TDD (Parte 4) Alta y Actualización

lopez — Thu, 02 Jun 2011 10:05:00 GMT

Anterior Post
Siguiente Post

En el anterior post, implementé la recuperación de los datos de un Tema de libros. No implementé aún ninguna vista. Estoy escribiendo los tests, e implementando el código del controlador. Es hora de agregar un nuevo Tema (Subject), usando una acción del controlador.

Este fue mi primer test:

[TestMethod]
public void AddSubject()
{
    IList<Subject> subjects = GetSubjects();
    Subject subject = new Subject() { Name = "Chemistry" };
    SubjectController controller = new SubjectController(subjects);
    ActionResult result = controller.Create(subject);
    Assert.IsNotNull(result);
    Assert.IsTrue(subjects.Any(s => s.Name == "Chemistry"));
    Assert.AreNotEqual(0, subject.Id);
}

GetSubjects() es un método ayudante que presenté en el anterior posts. Retorna una lista de temas para tests. Agregué una nueva acción en la clase controladora, para que la solución compile:

public ActionResult Create(Subject subject)
{
    throw new NotImplementedException();
}

Compiló, y el test quedó en rojo:

Entonces, completé el método de acción con el código mínimo para que pase el test:

public ActionResult Create(Subject subject)
{
   subject.Id = this.subjects.Max(s => s.Id);
   subjects.Add(subject);
   return RedirectToAction("Index");
}

Pero quiero redireccionar a la vista de detalle luego de haber dado de alta un item. Agrego el test:

RedirectToRouteResult redirect = (RedirectToRouteResult)result;
Assert.IsTrue(string.IsNullOrEmpty(redirect.RouteName));
Assert.IsTrue(redirect.RouteValues.ContainsKey("id"));
Assert.AreEqual(subject.Id, redirect.RouteValues["id"]);
Assert.IsTrue(redirect.RouteValues.ContainsKey("action"));
Assert.AreEqual("Details", redirect.RouteValues["action"]);

Cambio el código de la acción para que cumpla con el nuevo requerimiento:

public ActionResult Create(Subject subject)
{
    subject.Id = this.subjects.Max(s => s.Id);
    subjects.Add(subject);
    return RedirectToAction("Details", new { id = subject.Id });
}

Ahora, el test en verde:

Seguí un camino similar para escribir el test de actualización de un Tema existente. Esta es la versión actual de ese test:

[TestMethod]
public void UpdateSubject()
{
    IList<Subject> subjects = GetSubjects();
    Subject literature = subjects.Where(s => s.Name == "Literature").FirstOrDefault();
    Subject subject = new Subject() { Name = "SciFi" };
    SubjectController controller = new SubjectController(subjects);
    ActionResult result = controller.Update(literature.Id, subject);
    Assert.IsNotNull(result);
    Assert.IsInstanceOfType(result, typeof(RedirectToRouteResult));
    RedirectToRouteResult redirect = (RedirectToRouteResult)result;
    Assert.IsTrue(string.IsNullOrEmpty(redirect.RouteName));
    Assert.IsTrue(redirect.RouteValues.ContainsKey("id"));
    Assert.AreEqual(literature.Id, redirect.RouteValues["id"]);
    Assert.IsTrue(redirect.RouteValues.ContainsKey("action"));
    Assert.AreEqual("Details", redirect.RouteValues["action"]);
    Assert.IsTrue(subjects.Any(s => s.Name == "SciFi"));
    Assert.AreEqual(literature.Id, subjects.Where(s => s.Name == "SciFi").Single().Id);
}

La acción del controlador:

public ActionResult Update(int id, Subject subject)
{
    Subject toupdate = this.subjects.Where(s => s.Id == id).Single();
    toupdate.Name = subject.Name;
    return RedirectToAction("Details", new { id = id });
}

Todos los tests en verde:

Algunas advertencias: los tests están revisando dos salidas: los cambios en el dominio (por ahor auna simple lista) y los resultados de las acciones (un tema MVC). Debería hacer refactor (seguramente en un futuro post) de la implementación del controlador, para separar las actualizaciones del dominio de los resultados de la navegación. Escribí el ejemplo de esta manera para mostrar cómo hacer refactor más adelante para conseguir una mejor implementación. Mi idea es tener un servicio de manejo de temas, y escribir con tests. Luego usarlo desde el controlador. Debería tambien tratar los casos de actualización de un item inexistente o la creación de un item ya existente.

Otra nota: no puse ninguna vista MVC todavía. Pero ahora ya tengo los tests como para agregarlas con confianza. Cuando las agregue, la conducta esperada del controlador ya estará probada.

Nos leemos!

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

Escribiendo una Aplicación usando TDD (Parte 3) Primer Detalle

lopez — Thu, 31 Mar 2011 09:55:00 GMT

Primer post de la serie
Próximo post de la serie
Anterior post de la serie

Desde el anterior post, he aplicado las sugerencias que dejaron en comentarios @MartinSalias y @theHumanFlag, gracias! (las dejaron en el post en inglés). Primero, renombré la clase Genre a Subject, usando las capacidades de refactoring de Visual Studio:

public class Subject
{
    public string Name { get; set; }
}

Segundo, ahora el controlador recibe y procesa un IEnumerable<Subject>:

public class SubjectController : Controller
{
    private IEnumerable<Subject> subjects;
    public SubjectController()
    {
    }
    public SubjectController(IEnumerable<Subject> subjects)
    {
        this.subjects = subjects;
    }
    public ActionResult Index()
    {
        return View(subjects);
    }
}

Hice los cambios con confianza, gracias a los tests.

Ahora, en este nuevo paso, agregué una acción: dado un Id, obtener el Subject. La propiedad Id agregada en Subjec:

public class Subject
{
    public int Id { get; set; }
    public string Name { get; set; }
}

Escribí el test:

[TestMethod]
public void GetSubjectForDetail()
{
    IEnumerable<Subject> subjects = new List<Subject>()
    {
        new Subject() { Id = 1, Name = "Mathematics" },
        new Subject() { Id = 2, Name = "Physics" },
        new Subject() { Id = 3, Name = "Biology" },
        new Subject() { Id = 4, Name = "Literature" }
    };
    SubjectController controller = new SubjectController(subjects);
    ActionResult result = controller.Details(1);
    Assert.IsNotNull(result);
    Assert.IsInstanceOfType(result, typeof(ViewResult));
    ViewResult viewResult = (ViewResult)result;
    Assert.IsInstanceOfType(viewResult.ViewData.Model, typeof(Subject));
    Subject model = (Subject)viewResult.ViewData.Model;
    Assert.AreEqual(1, model.Id);
    Assert.AreEqual("Mathematics", model.Name);
}

El test no compila. Agregué la acción en el controler:

public ActionResult Details(int id)
{
    return View();
}

El test compila, pero da en rojo. Vamos por el verde:

public ActionResult Details(int id)
{
    var model = this.subjects.Where(s => s.Id == id).FirstOrDefault();
    return View(model);
}

En este punto, tenía dos tests, que daban una lista de Subjects al controlador. Hice refactoreo de los test para separar la creación de la lista. Extraje el método:

private static IEnumerable<Subject> GetSubjects()
{
    IEnumerable<Subject> subjects = new List<Subject>()
    {
        new Subject() { Id = 1, Name = "Mathematics" },
        new Subject() { Id = 2, Name = "Physics" },
        new Subject() { Id = 3, Name = "Biology" },
        new Subject() { Id = 4, Name = "Literature" }
    };
    return subjects;
}

Ahora, el código del test es:

[TestMethod]
public void GetSubjectInDetail()
{
    IEnumerable<Subject> subjects = GetSubjects();
    SubjectController controller = new SubjectController(subjects);
    ActionResult result = controller.Details(1);
    Assert.IsNotNull(result);
    Assert.IsInstanceOfType(result, typeof(ViewResult));
    ViewResult viewResult = (ViewResult)result;
    Assert.IsInstanceOfType(viewResult.ViewData.Model, typeof(Subject));
    Subject model = (Subject)viewResult.ViewData.Model;
    Assert.AreEqual(1, model.Id);
    Assert.AreEqual("Mathematics", model.Name);
}

Todo en verde!

Como siempre, el código está en mi AjCodeKatas Google Project, esta vez en trunk/AppTdd/Step02)

Próximos pasos: más acciones, integrar alguna vista.

Nos leemos!

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