�ݺ�ߣ

Editor's Notes

• #4: Vamos a ver un poco de historia. Todo esto empezó en 2003 gracias a Dan North. Dan siempre se encontraba con los mismos problemas planteados por sus alumnos de cursos de TDD: - Por donde empiezo? - Qué testeo? - Como llamo a mis tests? - Como entiendo pq un test ha fallado?Su respuesta a todo esto fue BDD.
• #5: Lo primero que vio Dan es que estaban probando una herramienta que generaba una especie de documentación a partir de los proyectos de test (como el reporter de Jasmine). Vio que si los tests tenía como nombre una sentencia realizada con el lenguaje del dominio, les podía servir de documentación.
• #6: Lo segundo que se dio cuenta es que empezar los tests con la palabra should, ayudaba a mantenerse focalizado, ya que esa clase o método solo podía testear eso.
• #7: Un nombre expresivo es importante cuando un test falla. Al igual que un buen mensaje en el assert. Podemos saber pq ha fallado y lo que tenemos que arreglar con solo ver el nombre y el error.
• #8: La palabra comportamiento es más útil que la palabra test. Si nuestros métodos de test no están definiendo el comportamiento de nuestro sistema, tendremos una falsa sensación de seguridad. Centrarnos en el comportamiento nos ayuda muchísimo en el desarrollo. Y de aquí nació el término BDD y jBehave, el primer framework basado en jUnit.
• #9: Dan charló de todo esto con Chris Matts (el autor del libro Commitment) y le hizo ver la importancia del valor de negocio en BDD. Cuando estamos desarrollando nos tenemos que preguntar: qué es lo siguiente más importante que el sistema no hace? Y eso es lo que tenemos que implementar. Eso es lo que nos hará entregar el mayor valor.
• #10: Explicando todo esto a Chris Matts (el lenguaje utilizado en BDD) Chris le hizo ver que era lo mismo que un análisis. Lo que estaban describiendo los tests de Dan eran los requisitos del sistema. Se podían utilizar estos comportamientos para definir los requisitos de un sistema. Solo se necesitaba encontrar un vocabulario que todo el mundo pudiera utilizar y que eliminara las ambigüedades y faltas de entendimiento entre la gente de negocio y los desarrolladores.
• #11: BDD da un lenguaje ubícuo para la fase de análisis. Un lenguaje que puede entender la gente de negocio, los desarrolladores, testers, etc. Se desarrolla el patrón Given, When, Then.
• #12: Los criterios de aceptación tienen que ser ejecutables. Nos da velocidad, tests de regresión, etc.
• #13: Es como las histórias de usuario: CardConversationConfirmation
• #14: Pq hacemos todo esto?
• #15: Lo hacemos por dinero! En el 2012, la fuerza armada estadounidense pago 1 billón de dólares por un proyecto para mejorar el abastecimiento de las tropas. 7 años de desarrollo después todavía era utilizable y llevaba un coste de 1.1 billones de dólares extra.Obama healthcare costó 618 millones de euros y el dia que se lanzó no funcionaba.En lo que más pierde la industria del software es por no saber lo que necesitamos hacer.Obviamente antes de todo esto hay una etapa de descubrir estos requisitos. Real options, deliberate Discovery, featureinjection, impactmapping, etc.
• #16: Hacer este tipo de técnicas nos permites saltar el agujero que hay entre lo que unos y otros entienden de un proyecto. Esto viene de dar cosas por supuestas, de no preguntar, etc.“The single biggest problema in communicationistheillusionthatit has taken place” – George Bernard Shaw (Founder of London School of Echonomics)Como podemos salvar estas diferencias?
• #17: Con ejemplos. Si os paráis a pensar, siempre hemos trabajado con ejemplos. Pero estos ejemplos no se comunican.
• #18: Necesitamos diversidad cognitiva. Los grupos sin diversidad cognitiva tienden a llegar a consensos rápidos. Si yo me rehúno con unos amigos muy culés, llegaré a la conclusión que el Espanyol se va a dejar ganar contra el Madrid (y el campo aplaudirá) y que el Levante jugó primado (y mucho). Esto es cierto, pero podría no serlo.Si me reuno con gente que sepa de futbol y que sea de diferentes equipos, haré un estudio mucho más pormenorizado de los partidos.Cada uno es bueno sacando ejemplos de su área (happypath, cosas de desarrollo, testing, etc).
• #20: Living documentation. Una de las ventajas que nos da BDD es el de tener como resultado una documentación viva, que se modifica asiduamente, que se va a mirar siempre que hay dudas y que es ejecutable.
• #21: Ganamos en entendimiento compartido. Todas las partes saben de que están hablando.
• #22: Este es el patrón típico de BDD. Estas especificaciones hay que tratarlas como el código: - Que sean fáciles de leer y mantener. - Eliminar la duplicidad - tablas - scenariooutline + example
• #23: Y sobretodo ser expresivo. Centrarnos en el qué y no en el como. Un escenario no debe ser un script de test, on debe meterse en UI ni especificar los pasos que hay que hacer. Debe centrarse en temas de negocio. Si hace falta automatizar la UI tenemos que utilizar page objects.
• #25: Ciclo de BDD