Buenas!
Que os parece la idea? una locura no? De que conyo vas a hacer tests si no?
Pues mira, hay un grupo de gente, que dice que hacer tests de tu implementacion esta mal, porque tu implementation cambia, mejora, y entonces tienes que cambiar tus tests. No pasa nada si solo tienes 5 o 6 tests, pero cuando tienes 500 tests y re-estructuras tu codigo porque estaba volviendose eso un chaos que no entendia nadia, pues has tenido que cambiar todos tus tests relacionados con las clases que has re-estructurado, porque estas haciendo tests de tu implementation. Bien, eso es el pan de cada dia para muchos testeros, es lo que hay, y punto, vives con ello.
Bien, por eso la mayoria de gente no hace tests, porque son un conyazo que te cagas, y para que, si dentro de dos meses los vas a cambiar todos!
Tiene que haber una manera mejor de comprobar que tu aplicacion funciona, que hace lo que se supone que tiene que hacer. Da igual, como lo hayas decidido implementar, y por favor cambia la implementation todas las veces que quieras, si haces test de el comporamiento de tu aplicacion, no pasa nada. Por ejemplo:
hago un "post" con cierta informacion de una reserva y en la base de datos se me habra guardado la reserva con esa informacion.
Eso si que mola, y el codigo para hacer tus tests es mucho mas bonito e intuitivo. No tienes que ir "verificando" cada paso de tu implementacion, solo hay que asegurarse que tenga el compartamiento esperado.
Bueno, pues esto, se puede hacer de manera muy bonita usando los Stories the rspec. Aqui va un link si os mola la idea.
http://blog.davidchelimsky.net/articles/2007/10/21/story-runner-in-plain-english
Ta Luek!
Hey! insolente! Las especificaciones de alto nivel rollo story runner parece que molan un huevo. En eso estoy de acuerdo. En lo que no lo estoy tanto es lo de que los "otros" tests sean un rollo. Hay muchas razones por las que creo que es necesario testear a un nivel de grano más fino. Por ejemplo, podría decirte, así, al azar xD, que en un lenguaje dinámico como Ruby, donde no hay un compilador, simplemente para comprobar ya no que el comportamiento, sino que la sintaxis es correcta, los tests se hacen imprescindibles. Es la respuesta a los excepticos que viene de lenguajes estáticos y no toman en serio nada que puedas desarrollar en Ruby porque "no tiene compilador": "No necesito compilador, escribo pruebas".
Las historias de usuario, desde luego que ejercitan tu código y también pueden servir en este sentido. Sin embargo, son pruebas de muy alto nivel y para tener un nivel de coverage suficiente tendrías que probar todas las posibles entradas y todas las posibles salidas. Esto solo en algunos casos sencillos es posible (tus historias cubren todos los casos) pero a menudo es inviable.
Es solo una razón, de entre otras muchas. Ah! y el testing mola! y engancha!!
Ese Luismi!
Siento el retraso en contestar XD! tu sabes, mucho trabajo poco dinero :)
Te veo puesto en el tema del testing. Yo aun no me aclaro mucho con todo esto, pero lo que creo es que las historias son una capa encima de los tests de verdad. Con un lenguage mas natural, mas facil de explicar las cosas claramente, dentro de una syntaxis especificica, for example.
Given "tengo 100 euros en la cuenta"
When "I sacar 40 euros"
Then "I will have 150 euracos en la cuenta"
eeeeeeerrrrorr
"Te creias que tendrias 150 euros pero tienes solo 60"
Ahi estamos viendo un ejemplo de como fallaria una historia y una explicacion de que ha pasado.
Despues aun habria que escribir algo de codigo que hiciera lo que cuenta la historia, que son los "tests" o "especificaciones".
steps(:banco) do
Given "tengo $cantidad euros en la cuenta" do |$cantidad|
@cuenta.create_cuenta(:saldo => cantidad)
end
When "I sacar $cantidad euros" do |cantidad|
@cuenta.retirar(cantidad)
end
Then "I will have $cantidad euracos en la cuenta" do |$cantidad|
@cuenta.saldo.should == cantidad
end
end
Como veis aqui no hay nada especifico sobre la implementation de los metodos.
Solamente es un proceso para llegar a un disenyo que tenga sentido y este testeado.
>>>tendrías que probar todas las posibles entradas y todas las posibles salidas
Como bien dices aqui, lo importante es lo que entra y lo que sale.
Por algun de tus blogs lei que, el codigo tendria que hablar por si solo, ser practicamente la unica documentacion necesaria. Bueno, igual tenemos ante nosotros el pegamento entre el codigo y la documentation....
De alguna manera ya tenemos un esquema de los metodos que tendrian que haber en la clase de la cuenta; ahora los implementamos, como nos salga del rabo, si el comportamiento esta bien descrito, ya hemos triunfao, nuestro codigo esta bien disenyado, documentado y testeado.
Luismi hay algo xungo en el mundo del testing, algo huelo a culo de moro, ha llegado la hora de hacer cambios en nuestros habitos y sucumbir al poder de behaviour-driven-development, la evolucion de test-driven-development!
Que en verdad no es ninguna revelacion para los maestros del testing. Ellos seguro que hacian los tests de puta madre antes de que viniera BDD, ahora los demas seres mortales, tenemos un framework que nos ayuda a pensar como los pros.
Como bien dices con los Stories se pueden hacer especficaciones de todo, controladores, modelos, vistas, librerias externas, lo unico es que tu decides lo que quieres especificar en cada historia, y lo escribes con rspec. Si quieres te puedes saltar completamente la parte de la Historia y hacer unas especificaciones del controlador, o de las vistas, pero para que hacer esta division? simplemente especifica lo que te interese en la historia, lo mas importante, que es normalmente lo que te pide el cliente.
El hecho de que sea viable o no, aun no lo tengo claro, necesitaria mas ejemplos...
Pero lo que creo a bote pronto, es que las especificaciones seran mas claras con un historia que solo con los tests.
Para mi la facilidad de poder leerte un historia en ingles, espanyol, o cualquier otro idioma, es la mejor documentacion que me he encontrado hasta ahora. Antes, pensaba que eran los it "should do this and that", de rSpec, pero sin duda las historias son muchas mas faciles de entender para una persona que nunca ha visto tu codigo.