Cuando diseñamos un sistema grande, nos gusta basar nuestro diseño en la forma en la que será utilizado. De ese modo, las historias de usuario y los criterios de aceptación se convierten en mucho más que una meta final: son un principio rector para todo el sistema.
Esto resuelve varios problemas. Por ejemplo, elimina el exceso de ingeniería (ya que sólo escribimos lo que sabemos que el usuario necesita). Además, empezar por la interfaz pública reduce la aparición de riesgos al final del proyecto (nadie quiere una pesadilla de integración cuando se acerca la fecha de entrega).
Esta kata tiene como objetivo convertir esa experiencia a un problema que puede ser resuelto en un par de horas, con un programa primitivo sobre una cuenta bancaria. En este caso, nuestra interfaz de usuario consiste en sólo algunos métodos públicos - supongamos que estamos escribiendo una librería, pero los mismos principios se mantienen.
Es una forma fantástica de practicar el uso de pruebas de aceptación para guiar el diseño. Si se hace correctamente, como resultado se obtiene un sistema que evoluciona por sí mismo sin esfuerzos innecesarios y sin sorpresas desagradables al final. Verás cómo el método de trabajo outside-in puede ser una forma poderosa de crear software orientado a objetos.
Puedes intentar esto usando Mockist o Classicist TDD, pero el enfoque de Mockist es más adecuado. Considera utilizar el screencast de Sandro Mancuso como referencia.
Escribe una clase llamada Account que implemente la siguiente interfaz pública:
public interface AccountService
{
void deposit(int amount)
void withdraw(int amount)
void printStatement()
}
Esta es la especificación para una prueba de aceptación que expresa el comportamiento deseado:
Si un cliente hace un depósito de 1000 el 10-01-2012
Y un depósito de 2000 el 13-01-2012
Y retira 500 el 14-01-2012
Al imprimir su extracto bancario vería lo siguiente:
Date || Amount || Balance
14/01/2012 || -500 || 2500
13/01/2012 || 2000 || 3000
10/01/2012 || 1000 || 1000
int
s para las cantidades de dinero y para mantener los auxiliares lo más simple posible. En un sistema real, utilizaríamos un tipo de dato con precisión arbitraria garantizada, pero en este caso nos distraería del objetivo principal del ejercicio.A continuación Irene Piccoli y Pablo Martínez resuelven esta kata con Python. Te animamos a que practiques en compañía de nuestros craftspeople.