Luismi Cavallé dijo

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!!

7 Enero 2008 | 11:10 PM

Raimond Garcia dijo

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.

21 Enero 2008 | 05:12 PM