Test cada porción con su oveja - rspec, cucumber, etc


#1

Hola a todos

Este topic es más para conocer como debo proceder que dudas técnicas que
se me presentan, aunque seguro que ambas cosas están ligadas.

Yo ahora después de un tiempo desarrollando en Rails, testeando
ligeramente con shoulda y unit::test quiero mejorar mis desarrollos
utilizando un metodología BDD. Para ello, he empezado a empaparme de
Cucumber y también de rspec. Pero tengo dudas de donde acaban las
responsabilidades de cada “framework” (cucumber, rspec)

A mi entender Cucumber es útil en la definición de los criterios de
aceptación entre desarrolladores y clientes por la claridad en la que se
plasman las necesidades. Y creo que estos criterios se deben limitar a
detallar las funcionalidades de forma general de la aplicación. Por
ejemplo,

Escenario: Usuario no logueado visita página de login y se loguea
satisfactoriamente
Dado que el usuario no está logueado
Cuando visito la página de login
Y relleno el formulario correctamente
Y pulso el botón “login”
Entonces debo estar logueado
Y debo estar en la home

Este ejemplo muestra una funcionalidad básica, pero no cabe duda que se
podría entrar en mayor detalle, ¿hasta que punto? O ese detalle se
cubriría en test funcionales donde se comprueba la asiganción de
variables, los mensajes flash, etcétera.

Para resumir,

¿Quería conocer como estructuráis el código de test: unit, functional,
integration, acceptance o por otro lado models, controllers, views,
helpers?

¿Qué se debe testear en cada uno de los ámbitos, si existen algunas
buenas prácticas o cómo diferenciar donde cae cada cosa?

Un saludo y gracias


#2

2009/3/2 Paco G. removed_email_address@domain.invalid

Hola a todos

Este topic es más para conocer como debo proceder que dudas técnicas que
se me presentan, aunque seguro que ambas cosas están ligadas.

Una buena presentación sobre el scope de cada tipo de test es esta,
espero
que te ayude:

http://www.scribd.com/doc/3197852/Fast-Sexy-and-Svelte-Rails-Testing


#3

Hola Paco,

hace poco tuvimos un evento en el madrid-rb, en el que Mathias nos
habló sobre testing y demás. Era un tema del que ya habíamos sacado
algunas conclcusiones en la pasada Conferencia Rails, gracias a las
charlas de David C. [1], Raimon y Nando [2] y los tíos de
BeBanjo [3]

Te recomiendo las tres, la verdad.

Por último te diré, que en La Coctelera, nosotros hacemos tets
unitarios con Test::Unit y shoulda, así como tests funcionales con
Test::Unit. Nos faltan tests de integración, que supongo que si nos
pusiéramos, los haríamos con Cucumber + webrat | selenium | watir

[1]
http://isabel.dit.upm.es/component/option,com_docman/task,doc_download/gid,842/Itemid,74/

[2] http://revoluser.com/talks/278

[3]
http://isabel.dit.upm.es/component/option,com_docman/task,doc_download/gid,850/Itemid,74/

2009/3/2 Paco G. removed_email_address@domain.invalid:


#4

Gracias Fernando

Ya repase esas charlas, hace bien poco, cuando las descubrí porque
durante un tiempo no pude entontrarlas con Mr. Google.

Creo que voy a darles otra vuelta para empaparme aún más.

Pero creo que al final cada uno debe establecer sus criterios en función
de las herramientas que utilice

Un saludo

Fernando B. wrote:

Hola Paco,

hace poco tuvimos un evento en el madrid-rb, en el que Mathias nos
habló sobre testing y demás. Era un tema del que ya habíamos sacado
algunas conclcusiones en la pasada Conferencia Rails, gracias a las
charlas de David C. [1], Raimon y Nando [2] y los tíos de
BeBanjo [3]

Te recomiendo las tres, la verdad.

Por último te diré, que en La Coctelera, nosotros hacemos tets
unitarios con Test::Unit y shoulda, así como tests funcionales con
Test::Unit. Nos faltan tests de integración, que supongo que si nos
pusiéramos, los haríamos con Cucumber + webrat | selenium | watir

[1]
http://isabel.dit.upm.es/component/option,com_docman/task,doc_download/gid,842/Itemid,74/

[2] http://revoluser.com/talks/278

[3]
http://isabel.dit.upm.es/component/option,com_docman/task,doc_download/gid,850/Itemid,74/

2009/3/2 Paco G. removed_email_address@domain.invalid: