"Hay algún fallo? Bien." No puedo creer que aún pase esto. Aquí no hacemos las cosas así! antes de escribir el código. La buena noticia es que siempre vais a tener Aquí estamos haciendo tests de aceptación, tests de integración, y tratando de capturar el comportamiento. Así es como funcionan juntos. Con Cucumber vosotros describís las funcionalidades, empezáis escribiendo Así que escribes la prueba, compruebas la salida, escribes la prueba, compruebas la salida. Así que, BDD y TDD, como dije antes, la frase 'diseño dirigido por el comportamiento' fue concebida por Bueno, esta idea ya tiene un tiempo, simplemente tenéis que retenerla en la cabeza. Capítulo 5: visión general de las pruebas Doblemente difícil, verdad? Por lo tanto, si escribes el mejor código posible En el proceso en cascada, antes de empezar, tendríais que tener un equipo de calidad aparte, Entonces, una vez que habéis implementado la funcionalidad correctamente, esta pasará Cucumber en verde. Estamos probando continuamente, cada semana tenemos nuevo código. Este argumento pertenece al Agile Mafiesto, y dice, Este es Brian Kernighan, el autor - uno de los héroes de los laboratorios Bell, autor del Este es un artículo de hace un año y medio, y reza "Por qué son caras las cosas?" Esto fue hace año y medio. Aún son raros. Sólo el 12% de las desarrolladoras de software La depuración es el doble de difícil que escribir el código en primer lugar. Las pruebas nunca pueden demostrar la [ausencia] de errores, sólo su [presencia], verdad? Muy bien, este otro es Djikstra. Tenéis que rellenar los espacios en blanco. Si lo leéis un par de veces lo veréis. Tú eres el responsable de probar tu código, no cualquier otro. Y entonces cuando se superan las pruebas RSpec se itera internamente hasta que se supera el RSpec. Y las herramientas están altamente automatizadas, no como en la afirmación anterior. Y podéis ver que su estudio no dice que los fallos sean inherentes al diseño, Y volvéis atrás, y seguís con el desarrollo. con un buen proceso, tendremos calidad del software, en lugar de que haya un equipo específico de tal manera que todas estas fases las llevasen a cabo diferentes grupos de personas. Así que mi trabajo, de alguna manera, en TDD se hacen definiciones de pasos, y realmente se escriben tests unitarios y tests funcionales fallan. Entonces implementáis los métodos que faltan. hacen pruebas completamente automatizadas. El 10% hacen todas las pruebas manualmente, está claro? hay tantos fallos en el código. También dice que los entornos de pruebas completamente automatizados son raros. la primera vez, no serás capaz de depurarlo, ya que es el doble de difícil. las historias a implementar, fallan, entonces se invocan las implementaciones, las pruebas RSpec, las pruebas actualizadas, porque las estáis escribiendo mientras escribís el código, o incluso antes. libro de Kernighan y Ritchie sobre C que seguramente tengáis. o asegurar que tu código tiene calidad. Con Agile, esto es parte de todo lo que hacemos. que se encargue de asegurarlo, y que te castigarán si no la tienes. se supone que el equipo de calidad debería añadir calidad a tu código, sino que derivan de un mal testeo de funcionalidades. Un mal proceso de pruebas es la razón por la cual un grupo de personas que se encontraban confundidas acerca del desarrollo dirigido por las pruebas.