Banco

Resumen

Cuando diseñamos un sistema grande, nos gusta basar nuestro diseño en la forma en que el sistema 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 transformar 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 manteniendo los mismos principios.

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 extraños y sin sorpresas desagradables al final. Verás cómo el 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. 

Instrucciones

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()
}

Reglas

• No puedes cambiar la interfaz pública de esta clase.

Comportamiento deseado

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

Observaciones

• Estamos utilizando ints 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.
• No te preocupes por el espaciado y la sangría en el output statement. (Si quieres, puedes indicarle a tu prueba de aceptación que ignore los espacios en blanco).
• Utiliza la prueba de aceptación para guiar tu progreso hacia la solución. Sandro aplica esto al hacer que todos los métodos no implementados lancen una excepción. De este modo, puede ver inmediatamente lo que queda por implementar cuando ejecuta la prueba de aceptación.
• Siempre que tengas una duda, opta por la solución más sencilla!

Enlaces de interés

Artículos en Inglés

• Bank kata in Haskell - dealing with state
• Bank kata in Haskell - printing a statement
• Bank kata in Haskell - using and testing date
• A case for outside-in development

Soluciones

• En C# por Liam Griffin-Jowett
• En Java por Sandro Mancuso
• En Java por Richard Wild
  

  Vídeos