9:59:59.000,9:59:59.000
"Hay algún fallo? Bien." No puedo creer que aún pase esto. Aquí no hacemos las cosas así!

9:59:59.000,9:59:59.000
<i>antes</i> de escribir el código. La buena noticia es que siempre vais a tener

9:59:59.000,9:59:59.000
Aquí estamos haciendo tests de aceptación, tests de integración, y tratando de capturar el comportamiento.

9:59:59.000,9:59:59.000
Así es como funcionan juntos. Con Cucumber vosotros describís las funcionalidades, empezáis escribiendo

9:59:59.000,9:59:59.000
Así que escribes la prueba, compruebas la salida, escribes la prueba, compruebas la salida.

9:59:59.000,9:59:59.000
Así que, BDD y TDD, como dije antes, la frase 'diseño dirigido por el comportamiento' fue concebida por

9:59:59.000,9:59:59.000
Bueno, esta idea ya tiene un tiempo, simplemente tenéis que retenerla en la cabeza.

9:59:59.000,9:59:59.000
Capítulo 5: visión general de las pruebas

9:59:59.000,9:59:59.000
Doblemente difícil, verdad? Por lo tanto, si escribes el mejor código posible

9:59:59.000,9:59:59.000
En el proceso en cascada, antes de empezar, tendríais que tener un equipo de calidad aparte,

9:59:59.000,9:59:59.000
Entonces, una vez que habéis implementado la funcionalidad correctamente, esta pasará Cucumber en verde.

9:59:59.000,9:59:59.000
Estamos probando continuamente, cada semana tenemos nuevo código.

9:59:59.000,9:59:59.000
Este argumento pertenece al Agile Mafiesto, y dice,

9:59:59.000,9:59:59.000
Este es Brian Kernighan, el autor - uno de los héroes de los laboratorios Bell, autor del

9:59:59.000,9:59:59.000
Este es un artículo de hace un año y medio, y reza "Por qué son caras las cosas?"

9:59:59.000,9:59:59.000
Esto fue hace año y medio. Aún son raros. Sólo el 12% de las desarrolladoras de software

9:59:59.000,9:59:59.000
La depuración es el doble de difícil que escribir el código en primer lugar.

9:59:59.000,9:59:59.000
Las pruebas nunca pueden demostrar la [ausencia] de errores, sólo su [presencia], verdad?

9:59:59.000,9:59:59.000
Muy bien, este otro es Djikstra. Tenéis que rellenar los espacios en blanco.

9:59:59.000,9:59:59.000
Si lo leéis un par de veces lo veréis.

9:59:59.000,9:59:59.000
Tú eres el responsable de probar tu código, no cualquier otro.

9:59:59.000,9:59:59.000
Y entonces cuando se superan las pruebas RSpec se itera internamente hasta que se supera el RSpec.

9:59:59.000,9:59:59.000
Y las herramientas están altamente automatizadas, no como en la afirmación anterior.

9:59:59.000,9:59:59.000
Y podéis ver que su estudio no dice que los fallos sean inherentes al diseño,

9:59:59.000,9:59:59.000
Y volvéis atrás, y seguís con el desarrollo.

9:59:59.000,9:59:59.000
con un buen proceso, tendremos calidad del software, en lugar de que haya un equipo específico

9:59:59.000,9:59:59.000
de tal manera que todas estas fases las llevasen a cabo diferentes grupos de personas. Así que mi trabajo, de alguna manera,

9:59:59.000,9:59:59.000
en TDD se hacen definiciones de pasos, y realmente se escriben tests unitarios y tests funcionales

9:59:59.000,9:59:59.000
fallan. Entonces implementáis los métodos que faltan.

9:59:59.000,9:59:59.000
hacen pruebas completamente automatizadas. El 10% hacen <i>todas</i> las pruebas manualmente, está claro?

9:59:59.000,9:59:59.000
hay tantos fallos en el código. También dice que los entornos de pruebas completamente automatizados son raros.

9:59:59.000,9:59:59.000
la primera vez, no serás capaz de depurarlo, ya que es el doble de difícil.

9:59:59.000,9:59:59.000
las historias a implementar, fallan, entonces se invocan las implementaciones, las pruebas RSpec,

9:59:59.000,9:59:59.000
las pruebas actualizadas, porque las estáis escribiendo mientras escribís el código, o incluso antes.

9:59:59.000,9:59:59.000
libro de Kernighan y Ritchie sobre C que seguramente tengáis.

9:59:59.000,9:59:59.000
o asegurar que tu código tiene calidad. Con Agile, esto es parte de todo lo que hacemos.

9:59:59.000,9:59:59.000
que se encargue de asegurarlo, y que te castigarán si no la tienes.

9:59:59.000,9:59:59.000
se supone que el equipo de calidad debería añadir calidad a tu código,

9:59:59.000,9:59:59.000
sino que derivan de un mal testeo de funcionalidades. Un mal proceso de pruebas es la razón por la cual

9:59:59.000,9:59:59.000
un grupo de personas que se encontraban confundidas acerca del desarrollo dirigido por las pruebas.