RailsConf Europe y rSpec

Despues de 3 dias por los Berlines absorbiendo informacion sobre Rails, creo que toca hablar de uno de uno de los puntos mas interesantes, rSpec.

rSpec:

Testing, Testing, Testing, en mi ultimo programa rideflyreservations.com (aun esta bajo construcción así que no me toquéis las pelotas) me he dado cuenta que hacer tests es muy importante. Porque? pues porque mi jefe me iba diciendo venga ahora quiero que los usuarios se puedan registrar, ahora quiero un Google Maps, ahora informes sobre las ventas, vale, pues a medida que iba incrementado la funcionalidad del sistema me iban petando cosas que había hecho antes, y me encontraba en la situación de ir haciendo cosas nuevas y arreglando lo que se iba rompiendo, lo cual es una ful de Estambul porque por un lao mi jefe se cabreaba porque las cosas antiguas no funcionaban y por otro lao se cabreaba aun mas porque tardaba mazo en implementar cosas nuevas ya que me pasaba casi todo el tiempo arreglando lo que se rompía. Como arreglar esta situación? mandando a tomar por culo a mi jefe y haciendo otro proyecto? siempre es una opción, pero no es lo idóneo, lo suyo es arreglar las cosas que se rompan y hacer test para que no se rompan mas, pero hacer test es un coñazo! pero bueno como así no puedo ir por la vida, voy a empezar a usar Rspec

Porque rSpec? un par de cosas que se me kedaron de la RailsConf:
1. Usando rSpec puedes utilizar el lenguaje que usa tu jefe para hacer los tests, por ejemplo "It should show the cheapest price for each company". Esto es un requerimiento del sistema y ademas lo puedo hacer un test... interesante... osea se, que puedo plasmar todos los requerimientos del sistema en tests, pero no nos mola la palabra tests, así que le vamos a llamar specs como los de rSpec, que solo hacen specs para las especificaciones de la aplicación. Entonces tienes todos tus specs montados y se los puedes enseñar a tu jefe, porque rSpec tiene una movida que te saca la documentación del sistema con todos los specs que tienes definidos.

Vale que quiere decir esto, pues que después de unas cuantas conversaciones con el cliente puedes montarte todas las especificaciones del sistema, enseñarselas y si lo has plasmado todo bien, solo tienes que ir implementando estas especificaciones y cuando las tienes todas implementadas ya has acabado, lo cual es un logro, porque yo nunca se cuando coño voy a acabar un proyecto, pero de esta manera igual puedes estimar mejor lo que te va a tardar hacer los requerimientos del sistema.

2. No se puede estimar cuanto vas a tardar en hacer un proyecto si te dan una lista de tareas en plan "registrar usuarios", "fácil de usar", "quiero informes de todo..." un pokito de por favor!

Lo que decía la penya de la conferencia es que, tienes que identificar un requerimiento y la utilidad de ese requerimiento, porque igual te faltan otros 8 requerimientos que no te han dicho para conseguir esa utilidad.
Por ejemplo "recolectar direcciones de los usuarios" vale tu piensas eso te lo monto en un momento, le dices eso esta hecho en un día. Vale, pero después de dice "hombre, pero le meto cualquier cosa en el formulario de la dirección y me lo acepta, eso no es lo que yo quería, ahora quiero que me valides el código postal, porque sino vaya ful" y tu le dices, vale, no problemo , se lo haces y te dice, "bueno, pero aun con el código postal no me sale en el google maps, porque me ponen la dirección mal", Ahora ya empezamos a llegar ha algún lado. El pavo quería la dirección de un usuario para sacarlo en el google maps, ese es el beneficio principal de recolectar la dirección del usuario, y para conseguirlo lo que hay que hacer es que cuando el usuario te ponga la dirección le preguntas al google si encuentra la dirección sino, le dices al usuario, mira lo siento pero no encuentro la dirección porque me falta, la calle, o la ciudad o el código postal o el numero de la calle, vamos un montón de validaciones que si hubieras sabido desde el principio hubieras podido estimar mucho mejor lo que te iba a llevar completar el requerimiento "recolectar la dirección de los usuarios". Y lo contrario también es muy importante, no te montes una funcionalidad super segura que no puede petar nunca, si no va a servir para nada! Si recolectamos la dirección del cliente, pero ni le mandamos nada, ni tiene que salir su dirección en ningún sitio, no te pegues la matada de validar cada campo de la dirección y dedicate a lo que de verdad es importante para que funcione el programa.

Bueno, voy a dejar de torrarla ya, otro día os cuento algo mas.

Venga hasta luego cocodrilos!

servido por Raimond 1 comentario compártelo