1
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í!

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

3
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.

4
99:59:59,999 --> 99:59:59,999
Así es como funcionan juntos. Con Cucumber vosotros describís las funcionalidades, empezáis escribiendo

5
99:59:59,999 --> 99:59:59,999
Así que escribes la prueba, compruebas la salida, escribes la prueba, compruebas la salida.

6
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

7
99:59:59,999 --> 99:59:59,999
Bueno, esta idea ya tiene un tiempo, simplemente tenéis que retenerla en la cabeza.

8
99:59:59,999 --> 99:59:59,999
Capítulo 5: visión general de las pruebas

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

10
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,

11
99:59:59,999 --> 99:59:59,999
Entonces, una vez que habéis implementado la funcionalidad correctamente, esta pasará Cucumber en verde.

12
99:59:59,999 --> 99:59:59,999
Estamos probando continuamente, cada semana tenemos nuevo código.

13
99:59:59,999 --> 99:59:59,999
Este argumento pertenece al Agile Mafiesto, y dice,

14
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

15
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?"

16
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

17
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.

18
99:59:59,999 --> 99:59:59,999
Las pruebas nunca pueden demostrar la [ausencia] de errores, sólo su [presencia], verdad?

19
99:59:59,999 --> 99:59:59,999
Muy bien, este otro es Djikstra. Tenéis que rellenar los espacios en blanco.

20
99:59:59,999 --> 99:59:59,999
Si lo leéis un par de veces lo veréis.

21
99:59:59,999 --> 99:59:59,999
Tú eres el responsable de probar tu código, no cualquier otro.

22
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.

23
99:59:59,999 --> 99:59:59,999
Y las herramientas están altamente automatizadas, no como en la afirmación anterior.

24
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,

25
99:59:59,999 --> 99:59:59,999
Y volvéis atrás, y seguís con el desarrollo.

26
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

27
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,

28
99:59:59,999 --> 99:59:59,999
en TDD se hacen definiciones de pasos, y realmente se escriben tests unitarios y tests funcionales

29
99:59:59,999 --> 99:59:59,999
fallan. Entonces implementáis los métodos que faltan.

30
99:59:59,999 --> 99:59:59,999
hacen pruebas completamente automatizadas. El 10% hacen <i>todas</i> las pruebas manualmente, está claro?

31
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.

32
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.

33
99:59:59,999 --> 99:59:59,999
las historias a implementar, fallan, entonces se invocan las implementaciones, las pruebas RSpec,

34
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.

35
99:59:59,999 --> 99:59:59,999
libro de Kernighan y Ritchie sobre C que seguramente tengáis.

36
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.

37
99:59:59,999 --> 99:59:59,999
que se encargue de asegurarlo, y que te castigarán si no la tienes.

38
99:59:59,999 --> 99:59:59,999
se supone que el equipo de calidad debería añadir calidad a tu código,

39
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

40
99:59:59,999 --> 99:59:59,999
un grupo de personas que se encontraban confundidas acerca del desarrollo dirigido por las pruebas.