Justificación de Cucumber

[Michel Martens]

Cuál es el razonamiento o el requerimiento que lleva a alguien a usar Cucumber?

[banafederico]

En los casos que me ha tocado a mi es por la falsa ilusión de que el cliente final puede escribir tests.

Es muy buena pregunta, a ver que dicen los demas.

2014-03-18 18:41 GMT-03:00 Michel Martens <sov...@gmail.com>:

Cuál es el razonamiento o el requerimiento que lleva a alguien a usar Cucumber?

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a rubysur+u...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.

--

Federico Baña - Software Engineer

banafederico.com
+598 95 279 173

[Emilio Gutter]

La ventaja que yo le veo es para los desarrolladores tratar de hacer el esfuerzo de escribir los casos de test desde el punto de vista del negocio y no en un lenguaje técnico, al tiempo que manteniendo esa 'documentación' separada del código. 

Muchos pueden argumentar que eso mismo se puede lograr con rspec, minitest o incluso runit.. y que cucumber es un overhead innecesario .. lo cual puede ser cierto y termina siendo una cuestión de gustos.. 

a mi no me desagrada, y lo sigo usando..recientemente para crear una suite de test funcionales end-to-end sobre una aplicación legacy que no tenia ningun test. 

Escribí algo en este blog http://www.10pines.com/blog/posts/refactoring-legacy-code-story pero no llegue a la 2da parte que era donde iba a contar como usaba cucumber con capybara. En algún momento voy a tener tiempo de escribirlo y se los comparto.

Si comparto la idea de que en el 99,99% de los casos es un error creer que el cliente o un analista o un QA no-tecnico se van a sentar a escribir o mantener los cukes.

saludos,

Emilio

Para anular tu suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje a rubysur+u...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Guillermo Iguaran]

Igual que Federico en los proyectos en que vi que se usara era para darle al cliente la ilusión de poder escribir casos de prueba si así lo quería aunque nunca vi a ninguno intentar hacerlo.

No se, capaz los de marketing lo usaban para vender a los clientes la idea de que podían participar mas activamente en el proyecto.

Saludos

2014-03-18 16:41 GMT-05:00 Michel Martens <sov...@gmail.com>:

Cuál es el razonamiento o el requerimiento que lleva a alguien a usar Cucumber?

[Ernesto - OmbuShop]

2014-03-18 18:41 GMT-03:00 Michel Martens <sov...@gmail.com>:

Cuál es el razonamiento o el requerimiento que lleva a alguien a usar Cucumber?

Como todas las librerías, tienen sus cosas buenas y malas. 

Empiezo por lo bueno, comparado con otras librerías:

* Está bueno porque es más fácil de leer que tests escritos utilizando otras librerías. Por eso, todos los escenarios son una parte más de documentación de tu proyecto.

* Cuando entra alguien nuevo al proyecto, podés decirle que lea toda los scenarios de Cucumber para tener una idea de todo lo que hace la aplicación. Para mí, siempre es más fácil entender un escenario en Cucumber que en otras librerías, por el tema del lenguaje natural.

* También está buena la idea de que personas no técnicas puedan escribir escenarios y casos de prueba para tu aplicación. De esa forma, los que hacen QA no tienen que saber código para escribir tests de integración.

Lo malo:

* En todos los proyectos donde usé Cucumber, nunca nadie no técnico se puso a escribir un escenario. Al final los programadores terminamos manteniéndolo y una de las supuestas ventajas nunca se dio. Quizás en empresas gigantes, con departamentos de QA, o analistas funcionales, les sea más útil.

* Velocidad: El tema del lenguaje natural agrega un "overhead" que no sé si vale la pena, si al final del día los que mantienen los tests son programadores.

* Mantenibilidad: El tema del lenguaje natural mete un nivel más de indirección que hace que el código sea más difícil de mantener.

En OmbuShop tenemos 180+ escenarios escritos en Cucumber, pero estamos empezando a usar más Rspec + Capybara y menos Cucumber.

No vamos a reescribir todos los escenarios de Cucumber, porque me parece un desperdicio de tiempo. Pero cada test nuevo de integración lo estamos escribiendo en Rspec.

Para nuestro proyecto, los "trade-offs" de Cucumber no son suficientes.

Creo que existen proyectos en Ruby que justifican el uso de Cucumber, pero según mi experiencia son la gran minoría.

Saludos

--

Ernesto Tagwerker

Founder, OmbuShop  

Tu Tienda Online en Minutos

[Michel Martens]

Gracias por las respuestas, les contesto a todos.

El tema de que el cliente nunca escribe tests lo sospechaba.

Creo que hay dos aspectos para destacar:

- Las ventajas de contar con cierta estructura (Given, When, Then)
- Las ventajas del lenguaje natural

Lo del lenguaje natural tiene algunas contras, como dijo Ernesto.
Sobre todo para programadores, porque llevado al extremo es como
tener que escribir "Add two to the variable foo" en vez de foo +=
2. Es decir, por lo general esa economía es bienvenida (mientras
sea clara la intención).

Entonces me parece que lo que más valor aporta es la estructura,
el hecho de estar obligado a describir las condiciones en cierto
orden. Es así?

[Bruno Bonamin]

En mi caso me ha ayudado mucho a ordenar las ideas cuando tengo que empezar a trabajar en nuevas features, y arrancarlas pensando desde el lado del usuario con el idioma simple que es el inglés me ayuda a meterme en el "flow" y bajar a nivel unitario con rspec/ minitest cuando tengo que escribir algo de código de más bajo nivel.

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a rubysur+u...@googlegroups.com.

Para obtener más opciones, visita https://groups.google.com/d/optout.

--
Bruno Bonamin.

[Matias Mascazzini]

2014-03-18 18:41 GMT-03:00 Michel Martens <sov...@gmail.com>:

Cuál es el razonamiento o el requerimiento que lleva a alguien a usar Cucumber?

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a rubysur+u...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.

Si bien no sé a que te querés referir con la pregunta, a primera impresión me pareció un poco agresiva, te responderé lo que opino siendo un newbie en este asunto pero que lo vengo investigando:

Cucumber es una herramienta para: generar conversaciones acerca del comportamiento de una aplicación, que se transforma en una documentación viva (viva porque se ejecuta, viva porque cambia); comportamiento que debe ser independiente de la plataforma. Hoy podes hacerlo en Rails y la misma característica (feature) te tendría que servir, si mañana, tienen que pasar todo a JEE, porque el comportamiento esperado por el usuario es el mismo.

Cucumber se hizo para soportar una practica ágil llamada BDD o Desarrollo dirigido por comportamiento, esta practica sigue la filosofía de "hacer software que importe" (que importe al cliente, que le agregue valor), entre i) hacer lo correcto y ii) hacerlo correctamente BDD elige darle prioridad a la primera.

En un mundo ideal, a uno como programador le debería de llegar una historia de usuario con al menos 1 escenario y a partir de ahí, conversando con el "cliente" van a ir surgiendo los casos extremos. Pero la idea es que esos escenarios marquen cuando esta completa la característica, lista en teoría para que el cliente la acepte. 
Tranquilamente te podrían pasar la característica en un archivo de texto, cargarla en un formulario, o dentro del sistema que usen para registrar las historias de usuario y sus escenarios. Pero ojo con la palabra "cliente", que al ser una practica ágil no siempre es lo mismo.

En este mundo ideal, Cucumber ve a tu aplicación como una caja negra, no tiene porque acceder a tu aplicación.

Que los test de cucumber queden en verde no es el objetivo, es solo una consecuencia. Hay un articulo, del creador, de porque quitaron las "rueditas de entrenamiento" (algo que así bastante muy fácil crear automatizar las pruebas) http://aslakhellesoy.com/post/11055981222/the-training-wheels-came-off  

Por qué elegir Cucumber frente a otras herramientas para hacer BDD?
además de la extensa documentación (en varios idiomas, incluido el Español) y del soporte de Gherkin para 32 idiomas, esta la cantidad de lenguajes y tecnologías que soporta, con lo cual (en teoría) sería más fácil hacer esa conversión de tecnología que cite antes.
Más info. en https://github.com/cucumber/cucumber/wiki

Me gustaría poder justificarlo con mayor profundidad, pero aun soy newbie.

Que vendan Cucumber a sus clientes y no apliquen la metodología como corresponde, no es culpa de la herramienta sino de quien la usa, esta la gente que desarma las cosas con un cuchillo, esta la gente que busca el Pozzidriv porque no es lo mismo que un Phillip.

Comparto que su gran punto débil es el lenguaje natural, hay muchas formas de expresar lo mismo y depende más de la persona que lo expresa que de la cosa en si misma. Te imaginas un "Dado k toy en el sistema y aprieto el cosito, sale el cartelito con TKM". Pero es un lenguaje natural estructurado, estructurado en la historia de usuario y en los escenarios (precodición, acción y resultado esperado), creo que en otras metodologías le decían "contrato" o minicontrato; herraimentas como el EA (enterprise architect) incluyen la posibilidad de agregar esto en los mismos casos de uso. Solo es cuestión de buscar la justificación de la razon de UML.

Si la empresa o el equipo no comporten la filosofía de lo que propone y sigue la práctica de BDD, no deberían practicarla. Es pretender ser una cosa que no son. Obviamente hay muchas otras formas de resolver los problemas no tienen porque seguir BDD.

Les recomiendo el libro "Especificaciones por Ejemplos", que hace referencias a como lo solucionaron diferentes equipos de muy diferentes empresas. Que también lo recomiendan en www.cukes.info

Por qué hacer BDD/TDD?
creo que sería tema para otro tópico, es más escapa un poco a la lista, pero te puedo sintetizar lo que es a mi entender:
Es como construir a mano una red de seguridad, claro que es un dolor atar uno a uno cada nudo, cada nodo [a mi no me contrataron para atar nudos, me contrataron para construir un rascacielos], pero al final cuando tenes la red más o menos armada te da una sensación de seguridad cuando andas caminados por las vigas o el andamio. Sobre todo si hace meses que dejaste de practicar esas acrobacias, o si es otro al que le toca hacerlas hoy.

Saludos
Matías Mascazzini

Corrientes, Argentina

Me encuentras en:
LinkedIn: http://ar.linkedin.com/in/matiasmasca/es
Twitter: @matiasmasca
ComunidadTIC: @matiasmasca
---------
Le recomiendo visitar: www.ComunidadTIC.com.ar
"¿Eres Informático?"

PD: lo bueno de ciertas preguntas, es que te obligan a hacer un recorrido mental sobre la temática y a refrescar las cosas.

[Pablo Astigarraga]

Ojo que creo que nos estamos escapando un poco del scope de la pregunta.

Matias: no estas exactamente defendiendo cucumber sino defendiendo BDD en general - con lo que estoy de acuerdo, pero BDD (y TDD) son independientes del framework de testing que uses, se puede hacer con rspec o cutest o lo que venga en gana.

En mi experiencia personal cucumber como framework no agrega nada a lo que me da cualquier otro framework de testing y en el afan de querer ser usable por gente no tecnica arma todo un DSL que agrega tremenda complejidad al stack de tests. Dado que nadie no tecnico lo termina usando el tradeoff termina siendo siempre uno muy malo: mucha complejidad agregada cuando la gente que termina leyendo los tests se siente mas comoda leyendo codigo.

El motivo para introducirlo ha sido invariablemente la colaboracion con los clientes. No conozco casos de exito sobre esto.

Para anular tu suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje a rubysur+u...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Michel Martens]

2014-03-18 22:30 GMT-03:00 Matias Mascazzini <matia...@gmail.com>:
>
>
> Si bien no sé a que te querés referir con la pregunta, a primera impresión me pareció un poco agresiva, te responderé lo que opino siendo un newbie en este asunto pero que lo vengo investigando:

No entiendo por qué te pareció agresiva, justamente estoy investigando
este tema y la pregunta fue muy puntual: más allá de las
características técnicas, qué es lo que lleva a alguien a usar
Cucumber. Las respuestas que obtuve fueron recontra satisfactorias,
porque no trataron de explicarme lo que es Cucumber sino que me
explicaron qué los motiva a usarlo, que era justo lo que buscaba.

[Guillermo Iguaran]

Hola Matias: Solo para dejar en claro, no creo que Michel ni ninguna de las respuestas anteriores incluyendo las mias estemos cuestionando el uso de TDD/BDD, estamos refiriéndonos es a hacer BDD usando Cucumber en particular.

Saludos

Para anular tu suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje a rubysur+u...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Matias Mascazzini]

Pablo,

perdón por irme del tema no entendía muy bien a que iba la pregunta, tenes razón que me fui por las ramas; sin embargo deje mi justificación para el uso de Cucumber. Obviamente no tengo punto de comparación con otras herramientas.

No comparto tu opinión respecto de "framework the testing", interpreto que no es la idea de la herramienta ni de la metodología, por lo menos en teoría, que el foco este en la prueba sino que las discusión debe girar entorno al comportamiento esperado.

Michel,

fue solo una primera impresión, lenguaje natural escrito justamente jajaja tiene sus desventajas.

Saludos
Matías Mascazzini

Corrientes, Argentina

Me encuentras en:
LinkedIn: http://ar.linkedin.com/in/matiasmasca/es
Twitter: @matiasmasca
ComunidadTIC: @matiasmasca
---------
Le recomiendo visitar: www.ComunidadTIC.com.ar
"¿Eres Informático?"

[Matias Mascazzini]

Las disculpas del caso Guillermo y los demás, no quise decir puntualmente, en el primer mail, que estuvieran ustedes cuestionando la técnica, incluso creo estar más cercano a lo que expreso Emilio.

Quise expresarlo desde un caso general de mal uso y enfatizar que para usar una herramienta de una técnica primero hay que respectar la técnica.

Saludos
Matías Mascazzini

Corrientes, Argentina

Me encuentras en:
LinkedIn: http://ar.linkedin.com/in/matiasmasca/es
Twitter: @matiasmasca
ComunidadTIC: @matiasmasca
---------
Le recomiendo visitar: www.ComunidadTIC.com.ar
"¿Eres Informático?"

[Emilio Gutter]

Hola Michel,

2014-03-18 21:26 GMT-03:00 Michel Martens <sov...@gmail.com>:

Gracias por las respuestas, les contesto a todos.

El tema de que el cliente nunca escribe tests lo sospechaba.

Creo que hay dos aspectos para destacar:

- Las ventajas de contar con cierta estructura (Given, When, Then)
- Las ventajas del lenguaje natural

Lo del lenguaje natural tiene algunas contras, como dijo Ernesto.
Sobre todo para programadores, porque llevado al extremo es como
tener que escribir "Add two to the variable foo" en vez de foo +=
2.

Creo que hay un error conceptual muy común detrás de esa frase. Mucha gente escribe en lenguaje natural lo mismo que expresa el lenguaje tecnico, cuando la idea es expresar en lenguaje natural los requerimientos del negocio que son difíciles de expresar con ese nivel de abstracción en el lenguaje técnico. Este post de concordion tiene unos ejemplos para marcar la diferencia:

http://www.concordion.org/Technique.html

 

Es decir, por lo general esa economía es bienvenida (mientras
sea clara la intención).

Entonces me parece que lo que más valor aporta es la estructura,
el hecho de estar obligado a describir las condiciones en cierto
orden. Es así?

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.

[Gaston Ramos]

El Tue, 18 de Mar de 2014, a las 09:26:00PM -0300, Michel Martens dijo:

>
> Entonces me parece que lo que más valor aporta es la estructura,
> el hecho de estar obligado a describir las condiciones en cierto
> orden. Es así?

Estoy de acuerdo con lo del orden y la estructura, creo que eso ayuda
bastante a mantener las cosas claras. Usé cucumber hace un tiempo
atrás cuando recién había salido, en ese momento me encantó.
Ahora con un poco más experiencia y habiéndo pasado por varios
proyectos, algunos desde cero y otros legacy mis preferencias han cambiado
y siempre trato de mantener las cosas lo más simple posible.
Lo que he notado que es que la mayoría de las veces sin importar el framework
los tests se van volviendo complicados de mantener en el tiempo, se van
desordenando en diferentes sentidos, así que mi conclusión y es usar lo más
simple posible (minitest o cutest) y poner el esfuerzo que en los tests sean
claros simples y fáciles de leer.

>
> --
> Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
> Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a rubysur+u...@googlegroups.com.
> Para obtener más opciones, visita https://groups.google.com/d/optout.

--
“Any fool can write code that a computer can understand. Good
programmers write code that humans can understand. ” - Martin Fowler


+-------------------------------------+
Gastón Ramos
http://gastonramos.com.ar/
GNU/Linux Counter user #450312

[Matias Mascazzini]

2014-03-18 21:26 GMT-03:00 Michel Martens <sov...@gmail.com>:

Entonces me parece que lo que más valor aporta es la estructura,
el hecho de estar obligado a describir las condiciones en cierto
orden. Es así?

Coincido que la estructura le agrega valor
- el mismo valor que genera utilizar historias de usuario.
y el además, con los escenarios, para determinar lo que el usuario espera que haga su aplicación
Given → Precondición
When → Acción
Then → Resultado
And / But → conectar step

Un punto para determinar cuando "esta listo" es "esta listo"

Y el punto en comparación con RSpec, es como se genera esta estructura, la facilidad que tiene para determinarla. No sé si allá alguna herramienta para agregarle a RSpec para que lo haga al revés, pero la estructura (si haces bien la tarea) la podes obtener de RSpec con un comando.

La facilidad para mantener en un mismo archivo la historia de usuario (narrativa) y sus escenarios (criterios de aceptación). No sé, o no me acuerdo ahora, como se haría esto en RSpec.

- El lenguaje Gherkin, te da la posibilidad de escribir en +37 idiomas diferentes, sin que esto lleve un mayor esfuerzo, máximo agregarle una instrucción explicita de enconding al principio de los steps.

http://gomix.fedora-ve.org/projects/ruby/wiki/Gherkin

- Las expresiones regulares le suman potencia, una peligrosa potencia (véase el caso de las training-wheels)

- Los diferentes lenguajes de programación, con sus herramientas asociadas donde podes usar las feature de Cucumber.

(véase la Wiki oficial de Cucumber).

En el caso de RSpec, no sé que tanto será compatible con otras herramientas derivadas de JBehave en otros lenguajes.

- Herramientas como Relish, en teoría, ayudarían a crear y administrar features sin estar en entornos de programación https://www.relishapp.com/ Pero en teoría se tendrían que escribir en forma conjunta, porque son el resultado de una conversación, conversación parte de las metodologías ágiles.

Pero como dijo Gastón, qué hacer cuando la cosa se va complicando a medida que avanza el proyecto?

Ayer leía un articulo de un blog (perdi el link) donde el tipo decía que las .features se pueden ir acomodando en una cierta estructura de directorios, y que dejarlos así como /features & /features/steps/ es un anti-patrón. Personalmente aun no he indagado al respecto.

Muy buenos aportes desde la praxis, nos seguimos leyendo.

[Pablo Astigarraga]

La facilidad para mantener en un mismo archivo la historia de usuario (narrativa) y sus escenarios (criterios de aceptación).

Capaz que yo soy un poco extremista pero no veo por que no se puede hacer esto con tests en código (cutest + capybara por ejemplo) y comentarios en cada test con la narrativa de lo que va pasando. 

--

Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.

Para anular tu suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje a rubysur+u...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Michel Martens]

2014-03-19 8:10 GMT-03:00 Emilio Gutter <egu...@gmail.com>:
>> Lo del lenguaje natural tiene algunas contras, como dijo Ernesto.
>> Sobre todo para programadores, porque llevado al extremo es como
>> tener que escribir "Add two to the variable foo" en vez de foo +=
>> 2.
>
>
> Creo que hay un error conceptual muy común detrás de esa frase. Mucha gente
> escribe en lenguaje natural lo mismo que expresa el lenguaje tecnico, cuando
> la idea es expresar en lenguaje natural los requerimientos del negocio que
> son difíciles de expresar con ese nivel de abstracción en el lenguaje
> técnico. Este post de concordion tiene unos ejemplos para marcar la
> diferencia:
> http://www.concordion.org/Technique.html

Muy buen punto, porque lo que puse fue una exageración. Y lo que dice Emilio
aplica para tests (con cualquier herramienta) y para comentarios en el código.

Como dice el proverbio, el código tiene que explicar el cómo y el comentario
tiene que explicar el porqué.

[Ernesto - OmbuShop]

Muy buena la discusión.

Creo que uno de los casos más útiles que he visto de Cucumber es como "Documentación que testea"

Por ejemplo: https://www.relishapp.com/rspec/rspec-core/v/2-0/docs/pending/pending-examples

Rspec usa Cucumber para documentar (parte de) su API y correr sus tests.

Me parece muy interesante ese caso de uso. En vez de escribir un README/wiki gigantesco, podés escribir escenarios que describan el comportamiento y también sirvan para testear/documentar.

[Leandro Marcucci]

Me parece que salvo la posibilidad de traducir el behaviour a varios idiomas, cucumber no ofrece nada distinto a otros frameworks para hacer testing.

No conozco casos de users/clientes/gente afuera del equipo de desarrollo en un proyecto que escriban tests, ni de developers que capitalicen tener la suite escrita en Gherkin.

Si alguien puede compartir casos en los que usen el output que produce Cucumber de una manera que genere más beneficios que el formato ‘doc’ de rspec por ejemplo, me gustaría leerlos. Programar tests usando expresiones regulares esta mal. Mal.

<troll-ish>
Después, leo que muchos destacan el lenguaje natural, o que Cucumber es un shortcut para documentar la aplicación. Me parece que Cucumber es mediocre para documentar, y que el tiempo que se pasa escribiendo en cucumber, se puede invertir mejor en una wiki. Escribiendo lenguaje natural. Que cuente cómo funciona el negocio, y qué partes del código llevan eso adelante.

También se puede usar lenguaje natural en la herramienta que elijan para trackear user stories. O en un cuaderno, o una presentación para el cliente. O charlando. Incluso en un pizarrón. El código es código.
</troll-ish>

--
L

On Tuesday, March 18, 2014 at 6:41 PM, Michel Martens wrote:

> Cuál es el razonamiento o el requerimiento que lleva a alguien a usar Cucumber?
>

> --
> Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.

> Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a rubysur+u...@googlegroups.com (mailto:rubysur+u...@googlegroups.com).
> Para obtener más opciones, visita https://groups.google.com/d/optout.

[Emilio Gutter]

Hola Leandro,

2014-03-20 12:51 GMT-03:00 Leandro Marcucci <leanucci@gmail.com>:

Me parece que salvo la posibilidad de traducir el behaviour a varios idiomas, cucumber no ofrece nada distinto a otros frameworks para hacer testing.

No conozco casos de users/clientes/gente afuera del equipo de desarrollo en un proyecto que escriban tests, ni de developers que capitalicen tener la suite escrita en Gherkin.

Si alguien puede compartir casos en los que usen el output que produce Cucumber de una manera que genere más beneficios que el formato ‘doc’ de rspec por ejemplo, me gustaría leerlos. Programar tests usando expresiones regulares esta mal. Mal.

<troll-ish>
Después, leo que muchos destacan el lenguaje natural, o que Cucumber es un shortcut para documentar la aplicación. Me parece que Cucumber es mediocre para documentar, y que el tiempo que se pasa escribiendo en cucumber, se puede invertir mejor en una wiki. Escribiendo lenguaje natural. Que cuente cómo funciona el negocio, y qué partes del código llevan eso adelante.

La diferencia es lo que se conoce como 'especificaciones ejecutables'. Una wiki (a menos que uses fitnesse o herramienta similar) tiene documentacion (aka especificación) pero no se ejecuta para comprobar que lo especificado concuerda con el código. Con lo cual pasa con mucha frecuencia que rápidamente la documentacion queda desactualizada y si queres saber lo que 'realmente'hace el sistema tenes que ir a ver el código. Mientras que cucumber u otras herramientas (como fitnesse) te permiten tener especificaciones que si no estan actualizadas, fallan y te obligan a mantenerlas al dia.

Saludos,

Emilio 

También se puede usar lenguaje natural en la herramienta que elijan para trackear user stories. O en un cuaderno, o una presentación para el cliente. O charlando. Incluso en un pizarrón. El código es código.
</troll-ish>

--
L

On Tuesday, March 18, 2014 at 6:41 PM, Michel Martens wrote:

> Cuál es el razonamiento o el requerimiento que lleva a alguien a usar Cucumber?
>
> --
> Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.

> Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a rubysur+u...@googlegroups.com (mailto:rubysur+u...@googlegroups.com).

> Para obtener más opciones, visita https://groups.google.com/d/optout.

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje de correo a rubysur+u...@googlegroups.com.

[Ariel Bici]

Hola

Yo no le encontraba el "chiste" a Cucumber, Fitnesse y demas hasta que leí Specification by Example de Gojko Adzic.

La realidad es que hay muchísimo material basura dando vueltas en el que utilizan mal esta herramienta (me refiero a Cucumber. De Fitnesse solo leí un libro de Uncle Bob, y Java me provoca episodios de artritis de solo leerlo).

Esperar que el cliente mismo escriba  las especificaciones es una fantasía. Pero lo que si se puede hacer es tomar todo el feedback del cliente, escribirlo como cukes y leerselo a ver si eso es realmente lo que el quiere. Las especificaciones tienen que estar escritas en muy alto nivel, como una persona cualquiera te describe un comportamiento. Por atras, que el test vaya todo lo bajo que quieras, que aprete "botonitos" y llame por telefono a ET si querés. Pero la "capa externa" es prosa.

Aca va un ejemplo. (Que no sera el pináculo de la perfección, esta incompleto, y apesta, pero puede servir :-) )

Feature: As a salesman I should be able to return items buyed by a client

Background:
  Given I am logged-in into sales

Scenario: Return some items

Given I go to returns
When It ask for a order code
And I give it a valid code
And The order is a sale
And The order is finished
Then It should ask for the items to be returned


Scenario: Fail to return some items

Given I go to returns
When It ask for a order code
And I give it a invalid code
Then I should see an error

Given I go to returns
When It ask for a order code
And I give it a valid code
But The order is not a sale
Then I should see an error

Cada linea es una regla de negocios. Seguramente la única especificación inicial del cliente va a ser "quiero poder hacer devoluciones". Pero cuando le lees algo así, va a entender de que viene la cosa y enseguida va a empezar a tirar frases del tipo "y que pasa si meto dos veces la misma orden de venta". Y ahí es donde conseguís el feedback que necesitas para seguir agregando especificaciones.

Esta "capa externa" se puede simplificar todavía mas y convertir cada escenario en una o dos linea usando anidado.

Given I go to returns and I insert a valid code
Then It should ask for the items to be returned

Bueno, ya me aburrí de escribir. Me voy a codear.

Saludos,

Ariel

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[IgorJorobus]

 Leí todo lo que pusieron. Me pareció muy interesante la información y defensa de Matías. Voy a explicar como veo a Cucumber:

 La idea es hacerle entender al cliente si lo que está expresando es lo que realmente quiere. Como decía alguien por ahí, que el cliente te escriba un cuke es una locura, el tipo está muy ocupado como para pasarse 2 o 3 horas escribiendo cukes. Lo que hay que hacer es uno escribirlos, mediante interpretar lo que dice el tipo que quiere. Entonces luego uno al final de la entrevista le lee los cukes, y en base a eso van saliendo los "casos raros".

 Procedimiento siguiente es(si uno trabaja con metodologías ágiles), establecer que de todo eso se puede hacer en un sprint, y realmente hacerlo, cargar los cukes en nuestras máquinas y asegurarse uno de cumplir lo que le prometió al cliente.

 Han habido casos que eh dejado de lado el TEST en si(no la escritura Gherkin), porque como ustedes saben, aveces escribir un test en cuke te tira mas para atrás que para adelante, te complica las cosas. Entonces cuando detecto eso, simplemente lo doy por pasado, cuando verifico VISUAL Y MANUALMENTE que ese mandato se esté cumpliendo. Entonces Cucumber pasa a ser mi herramienta, no su esclavo. No tiene que ser algo que haga perder tiempo, si no que nos de una seguridad, un respaldo, de que estamos haciendo lo correcto. 

 Outscope

 Y plus...si somos muy prolijos, ese Gherkin puede servir de documentación, si el usuario alguna vez reclama una. Me pasó en un proyecto que el tipo al final me pidió alguna documentación. Me tuve que poner a grabar tutoriales en video, porque no tenía ni un renglón de documentación -.- , y ya saben lo que implica hacer un manual desde 0, en cambio, si lo vamos haciendo mientras programamos...

[Gabriel C]

Coincido con Damián, me parece una cuestión de opinión o contexto si usarlo o no, si el cliente no va a estar leyendo los test y preferís escribir la documentación, no lo vas a usar, como gente que prefiere Unit::Test sobre Rspec.

El martes, 18 de marzo de 2014 18:41:28 UTC-3, Michel Martens escribió:

[Alexey Agapov]

Hola gente,

Muy interesante la discusion. Hoy me encontré con un post que habla de Cucumber como ejemplo de cargo cult programming, un aspecto a evaluar a la hora de decidir si usarlo en nuestro proyecto o no. 

http://www.jimmycuadra.com/posts/please-don-t-use-cucumber

 

--

Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a rubysur+u...@googlegroups.com.

[Luis Lavena]

Hola,

2014-04-08 18:08 GMT-03:00 Alexey Agapov <alexey...@gmail.com>:

Hola gente,

Muy interesante la discusion. Hoy me encontré con un post que habla de Cucumber como ejemplo de cargo cult programming, un aspecto a evaluar a la hora de decidir si usarlo en nuestro proyecto o no. 

http://www.jimmycuadra.com/posts/please-don-t-use-cucumber

Me sumo tarde a la "fiesta", pero creo el siguiente articulo le hace un poco más de justicia al tema:

http://tooky.co.uk/the-cucumber-test-trap/

En mi opinión personal, el uso (mejor dicho abuso) de los test de integración (usando herramientas como cucumber, capybara, rspec, o cosas en NodeJS), no es mas que una demostración del desconocimiento del mismo sistema que uno está escribiendo.

He usado todas las herramientas arriba mencionadas, otras en este hilo de discusión y muchas desconocidas, llegando a mi conclusión personal: el mayor problema no es la herramienta, sino el problema que se intenta resolver con esta.

Para explicarme mejor, hay que tener en claro lo siguiente: nosotros somos desarrolladores, entendemos software, lenguajes de programación, sistemas operativos, bases de datos relacionales, no-relacionales, memoria, caching, etc.

Pero muchas veces, a menos que estemos creando algo para nosotros, no entendemos el verdadero problema de cada negocio.

Entender el problema de negocio y el justificativo de que se necesite de A para hacer X conlleva una inversión de tiempo y cerebro no solo en escuchar por qué el cliente quiere que se haga una cosa, sino comprender esas necesidades.

Hay un gran vacío entre lo que un cliente sabe desde el punto tecnológico para poder comunicarse y lo que nosotros podemos entender desde el otro lado. Podrían verlo a esto como una linea telefónica que no solo tiene un retardo, sino que parte de lo hablado se pierde en el camino, ya sea por falla de la misma o por fallas de interpretación.

Cuántos aquí podrán decir que cuando un cliente pide A, trabajaron para generar ese requerimiento y luego concluyen, una vez que el cliente lo vé, que realmente no quería A, sino B?

Esto no es que "el cliente no sabe lo que quiere", sino que hay muchas veces discrepancias entre lo que se espera, lo que se realiza y lo que se obtiene, ya que las expectativas están armadas en base a una idea que gira en torno a un profundo conocimiento del negocio y que no se transmite en su totalidad a la otra parte.

Herramientas como Cucumber promueven este dialogo, pero han sido llevadas al punto de casos como "Cuando hago click aquí y escribo esto allá, pasa X cosa" en lugar de plantear una necesidad del negocio.

Esto puede pasar con Cucumber o cualquier herramienta. He visto test "unitarios" que crean mas de 5 registros en distintas tablas solo para hacer un assert de un total.

Y también he ganado mi pedacito de infierno por escribir los míos, y concluyo que es por mi falta de comprensión del verdadero problema a resolver.

Aprender a hablar el mismo idioma del cliente y comprender las necesidades del negocio es un largo camino e inversión, pero el beneficio obtenido es superior al de cualquier herramienta mágica que crean puede ayudar a saltar esa brecha.

Buenas noches,

-- 

Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

[Angel Java Lopez]

Un comentario, alguien que no programa en Ruby, y no usa Cucumber:

Un test "unitario", en la jerga original de Beck, creo entender de una vieja conferencia, no es un test que "toca una sola cosa" sino un test que se puede ejecutar sin necesidad de ejecutar otros test, en solitario.

Yo no separo entre tests "unitarios" y "federales", sino en test rapidos o no rapidos. En este caso, mi contexto es TDD, no Cucumber, y no tengo problema alguna vez, de agregar tests que pongan varios registros en varias tablas, para hacer algunos asserts. Ya llego a eso mas alla de TDD (no son en general un test surgido del flujo de trabajo de TDD), pero no tengo problema en ponerlo en la suite de tests. De hecho, documento algunas interacciones que bien pueden perderse si no estan en un test, clarito como huevo de tero ;-)

Insisto, mi contexto es TDD, como flujo de trabajo, no Ruby, no Cucumber.

Para aportar algo al tema Cucumber, y ligarlo con lo de arriba: lo que he visto que me sirve, es que alguna vez creo un DSL (Domain Specific Language) para que se puedan escribir mas faciles algunos tests no triviales. He llegado a archivos de texto (DSL externo), vistos desde lejos similares a Cucumber, que permiten que todos podamos escribir rapidamente algunos tests para documentar la conducta esperada, que aprendimos en el desarrollo del software, e interaccion con el cliente, y para que quede documentado en codigo (no en un documento que queda viejo a las dos semanas) como parte de los test. En general, esos tests pasan en verde, porque ya implementamos la conducta mas basica (los pasos pequenios) usando TDD. Entonces, para que sirven? Cuando un equipo nuevo toma el proyecto, corre todos los tests, y estan incluidos los clasicos de TDD, y esos tests adicionales, ya sea de codigo largo, ya sea de DSL. Supongo de esta experiencia, que Cucumber puede servir para eso: para que no se pierda en el tiempo, la conducta esperada del sistema, y responder a la pregunta: todavia lo sigue haciendo/cumpliendo, a pesar de los cambios que el equipo 2.0 esta introduciendo?

Como contra partida, aca tengo un sistema, donde no se hizo ni TDD ni este tipo de tests, y hoy nadie se acuerda cual es la conducta esperada en algunos casos de uso. Y cuando se cambia algo, nadie sabe que se rompio o no se rompio. 

Si hubiera TDD, y sale todo en verde luego de un cambio, aumenta la confianza de no haber roto algo. Pero se pierde el conocimiento de la conducta esperada en casos mas complejos. Los test adicionales de los que hablo son los que permiten que eso no se pierda, aun cuando se cambie de equipo. Mientras sean rapidos, se ejecutan en el set "ejecutar todos los tests" de cada maquina de desarrollo, antes de enviar un commit al repo, y no afectan al flujo de trabajo. Si algun test no es rapido, queda para el server de integracion continua. Insisto: es para mi mas importante lo de rapido o no rapido, que no afecte el flujo de trabajo, que si es unitario o federal ;-)

Aca destaco algo: hacer TDD, le da al equipo un gran entendimiento de lo que el sistema hace. Pero si cambia el equipo, lo que dejo TDD puede no bastar para transmitir todo lo que el equipo aprendio.

Nos leemos!

Angel "Java" Lopez

@ajlopez

--