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