Supongamos que un cliente nos contrata para desarrollar la siguiente aplicación:
"Quiero lanzar una aplicación monedero para el pago entre amigos. Cada usuario tendrá una cuenta con saldo. La idea es que se puedan hacer transferencias a tus amigos directamente desde la app. La aplicación permitirá al usuario ingresar dinero o retirarlo cuando quiera."
Pero aunque parece bastante claro, hay muchos detalles no especificados. No se puede aplicar TDD si no tenemos ejemplos concretos y certeros.
El ejercicio es el siguiente:
Imaginémonos que tenemos la oportunidad de entrevistarnos con el cliente para detallar mejor la aplicación. Nuestra tarea es obtener un listado de especificaciones ATDD. Es decir, un listado de ejemplos concretos y certeros, chequeable, y que cubra todas las posibilidades para que no haya lugar a malinterpretaciones de ningún tipo sobre las funcionalidades.
Evidentemente, los detalles los conoce el cliente, y no nosotros, así que para este ejercicio, por parejas, uno hará de cliente y otro hará de "tomador de requisitos".
El objetivo es tener unas especificaciones ATDD completa. Es decir, un documento firmado por ambas partes, con la relación de pruebas que si el software pasa con éxito se considera completamente terminado.
Nuestras soluciones no van a coincidir, pero el objetivo realemnte es ver si somos capaces de llegar a elaborar un lista de ejemplos válidos para utilizar la técnica TDD.