¿El TDC de pago?

Question

Yo un poco familiarizado con rspec [rubíes] y [Ficha] Scala. Yesturday pasé un tutor para Pepino. Lo que me gustó de pepino es que, además de describir escenarios (como lo haría con las pruebas espec- o de estilo xUnit) que tiene que aplicar la capa extra de indirección: traducir pasos de escenarios en expresiones de rubí. Para mí la creación innecesarias (?) Capas extra de indirección se siente como "peso pesado" J2EE vías, no como "ligero" camino rubí. Es comprensibilidad por los "expertos de dominio" La única ventaja de pepino? O hay algunos no evidentes ventajas técnicas (?) Para el desarrollador / probador así?

Answer 1

BDD, desde un punto de vista práctico, es altamente sinónimo de TDD. Rspec es un marco de prueba BDD, así como pepino.

que los interesados ??puedan leer y entender las especificaciones de aceptación de pepino es sin duda una ventaja clave, pero este hecho por sí solo no lo entiende en el beneficio real de pepino. Sus características y escenarios deberían crecer un poco en especificidad que el trabajo que se realiza para ellos se mueve a través de la cadena de valor del ciclo de desarrollo de su equipo.

Algunos equipos pueden tener un alcance analista a cabo el trabajo al comienzo del ciclo. A veces, este analista escribe especificaciones de aceptación pepinillo, pero el que escribe el primer borrador, que se puede esperar que sean bastante grano grueso. Ellos no pueden cubrir todos los caminos de la ONU-feliz.

A medida que los desarrolladores toman el trabajo, a menudo descubren casos extremos y escenarios que faltan. En este punto pueden tocar la base con el analista, y los resultados de tales conversaciones deben ser escritas en las características de pepino.

En mi experiencia los probadores han cultivado un ojo aún más crítica, por lo que no es raro verlos añaden aún más escenarios y características. Los probadores pueden también defectos destapar, que deben ser añadidos a los pepinos para protegernos de regresión.

El punto es que, además de proporcionar la documentación ejecutable para nuestro código, pepino también proporciona un repositorio para el estado de las conversaciones del equipo vis a vis las características están desarrollando.

No hay duda adicional por encima de todo esto. Sin embargo, vale la pena considerar la cantidad de sobrecarga ya está en proceso de su equipo, que podría servir para Pepino aerodinámica. Me parece que el pepino ayuda a reducir la cantidad de movimiento de piernas que sucede en la comunicación acerca de las características tanto dentro como fuera de la sala del equipo.

También debería mencionar que el pepino se piensa como pruebas de aceptación-pila completa, y por lo tanto debe ser menor de grano fino, en relación con las pruebas unitarias. Y el pepino no es un buen sustituto de las pruebas unitarias y de integración. También nunca recomendaría el uso de pepino para verificar los aspectos estéticos de la interfaz de usuario de la aplicación. Sólo lo utilizan para validar las acciones que podría tomar un usuario cuando se utiliza la aplicación.

Answer 2

El pepino está diseñado para ayudar a involucrar a las partes interesadas de negocios en los desarrolladores de refinación y probadores de la comprensión del sistema mediante la colaboración para crear escenarios que todo el mundo puede entender.

El acto de accionistas de la empresa de acoplamiento se paga, pues todo el mundo tiene una mejor comprensión, comienzan a compartir el mismo idioma y llevar a que el lenguaje en el código (ver Domain Driven Design "Ubiquitous Language"), que puede conducir a una mejor estimación, aprecio de alcance, conversaciones en torno a las opciones para lograr el mismo objetivo, etc., etc.

sin duda hay otras formas de alcanzar los objetivos. Por ejemplo, en nuestro proyecto de C # hablamos a través de los escenarios, las escribimos en un wiki y luego ponerlas en práctica usando un dominio específico poca costumbre de idiomas más bien como éste . Lo mismo se podría hacer en Ruby.

BDD es el proceso de aprendizaje de los lugares en los que pensábamos que sabíamos lo que estábamos haciendo, pero resultó que estábamos equivocados - la descubrimiento de la ignorancia . Con Característica de inyección y a nivel de unidad rel="noreferrer"> href="http://www.agilejournal.com/articles/columns/column-articles/1472-feature-injection", esto sucede en múltiples niveles de granularidad, todo el camino hasta la propia visión del proyecto. Tiende a pagar por sí mismo, pero usted no necesita un marco BDD hacer BDD .

Las conversaciones en BDD son las partes importantes, no la herramienta que utiliza para capturarlos (ayudé a escribir JBehave y todavía creer que esto es cierto). La automatización de pruebas de regresión también es importante reducir el esfuerzo manual que se eleva como el código base crece, y pepino, dispositivo o de otras herramientas de BDD le dan esto como un muy buen subproducto, del que también le ayudan a rastrear y expulsar, el conocimiento compartido .

Editar debería mencionar que la reutilización de los pasos también es importante, pero no hay mucha diferencia si se utiliza un marco de BDD o una conexión DSL para eso. Sí hace la diferencia entre un DSL y justo procesalmente imitando cada interacción con el usuario.

Answer 3

Depende de lo que quiere lograr.

Pepino implica una sobrecarga, puede ser difícil de acostumbrarse, toma tiempo para dominar.

Si desea que los expertos de dominio para poder leer sus pruebas, debería darle una oportunidad.

Por otro lado, si los desarrolladores son las únicas personas que leen sus pruebas, es probable que pueda pegarse a / rspec unidad de prueba / etc. y escribir sus pruebas de integración en esos marcos. Sin embargo es posible conseguir una documentación más legible alto nivel mediante el uso de pepino. Véase, por ejemplo rspec 2 núcleo descripciones características en pepino.