La palabra test, me toca las pelotas, no me mola, parece que tengas que escribir el doble de codigo para hacer lo mismo. Siento reconocer que yo no hago tests. Ahora bien si me dices haz especificaciones, pues ya te miro de otra manera, eso no suena tan mal :)
A eso es a lo que vamos con Behaviour Driven Developement y rSpec, no vamos a hacer tests vamos a definir con funcionana el sistema y asegurarnos de que nuestro codigo hace lo que esperamos que haga.
Cuatro puntos clave que consigues con esta filosofia:
1. Mas confianza para cambiar el codigo existente.
2. Sabes cuando has acabado porque todos tus especificaciones pasan.
3. Documentacion, en vez de comentarios escribes ejemplos.
4. NO escribes TESTS de cada funcion, escribes ESPECIFICACIONES del COMPORTAMIENTO del sistema.
Un cambio en la filosofia de trabajar, que creo que me va a hacer un mejor programador.
Echarle un vistazo a este video de Gregg Pollack de railseny
http://www.patchedsoftware.com/RailsEnvy-LoveTests.mov
servido por Raimond
sin comentarios
compártelo
Ahora mismo estoy usando hostingrails.com para enseñarles a los clientes el progreso con sus proyectos. Para mis proximos projectos, creo que voy a usar railsmachine.com. por que? por que te facilita facilita mucho el deployment de los proyectos.
Yo Normalmente tardo un par de horas en configurar la base de datos, subversion, los ssh keys y capistrano, y eso que todos los hostings tienen muy buenos tutoriales para hacer todo esto. Pero los de RailsMachine tiene una serie the gemas que te lo hacen todo por ti, asi que en literalmente 5 minutos tienes tu applicacion funcionando perfectamente en el servidor. Puedes poner hasta 5 aplicaciones distintas (usando 5 mongrels) y el plan mas barato es de $75/mes. Ademas usan VPS lo cual te da acceso root para hacer lo que quieras en tu servidor virtual. Muy jefe.
Exarle un vistazo al video de como hacer un deployment.
http://railsmachine.com/screencasts/RailsMachineIntro.mov
servido por Raimond
sin comentarios
compártelo
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
