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