Modular design with TDD

The slides we used during the workshop at http://conferencia2013.agile-spain.org.

It's only the exercise description. No explanations in it. Oh, and it's in spanish.

Transcript

1. DIRIGIDO POR PRUEBAS DISEÑO @jacegu @pasku1 MODULAR
2. LA APLICACIÓN
3. Iñaki Azkuna Alcalde de Bilbao
5. ROAR!!
6. ¿Cómo va a funcionar?
7. RESTRICCIONES: - Haz lo más simple que pueda funcionar. - Escribe el mejor código que puedas. - No hagas más de lo que pide la funcionalidad. - No introduzcas infraestructura si la funcionalidad no lo pide explícitamente. - No dependas de librerías si la funcionalidad no lo pide explícitamente.
8. ITERACIÓN I Un usuario puede registrarse con un nombre de usuario. Por ejemplo: “@pasku1” Si otra persona se ha registrado usando ese mismo nombre de usuario se produce un error. 10min
9. ITERACIÓN II Un usuario puede seguir a otros usuarios. Para hacerlo basta con conocer el nickname del usuario al que se quiere seguir. Cualquiera debe poder consultar a quién sigue un determinado usuario conociendo su nickname. 20min
10. MÁS RESTRICCIONES: - No se puede modificar el código escrito hasta ahora.
11. ITERACIÓN III Los registros de usuarios así como las listas de usuarios seguidos deben almacenarse de forma durable. 20min
12. MÁS RESTRICCIONES: - Situar el código escrito hasta ahora dentro de un namespace llamado “core” - Usar el código escrito hasta ahora como si fuera una librería externa. - El código de esta iteración debe estar en un namespace diferente. - Ese namespace puede tener una única dependencia del “core”.
13. ITERACIÓN IV Crear un mecanismo de entrega HTTP que permita acceder a la funcionalidad desarrollada hasta ahora. 30min
14. ITERACIÓN V Un usuario puede publicar “roars”. El resto de usuarios deben poder consultar todos los “roars” que un usuario con un determinado “nickname” ha escrito. 20min
15. ITERACIÓN VI Poner esta nueva funcionalidad disponible en mecanismo de entrega. Garantizar la durabilidad de los datos. 40min