in web we trust Fernando Blat's blog, freelance web developer

Supongamos que tengo un atributo validado por 'validates_uniqueness'. Si preparo un test en el que creo un objeto y le asigno a ese atributo un valor que ya existe en uno de ms fixtures, y compruebo que el objeot así generado no es válido, ¿estoy probando mi modelo o estoy realmente probando 'validates_uniqueness' ? De eso ya se encargan las pruebas del core de Rails. ¿No estaría repitiéndome? Lo mismo para las asociaciones sencillas.

Yo me limito a comprobar las validaciones y funciones del modelo escritas por mí; con la unica salvedad de 'validates_format_of' que también pruebo para comprobar que la expresión de formato es la correcta.

A veces he tenido que modelar relaciones complejas y sí escribo tests para las mismas, pero más que para cmprobar que funcionan lohago casi como documentación, para luego poder echar un vistazo a los fixtures y deducir qué se supone que hacen las relaciones :) Lo que no se me había ocurrido es pasar que todas las fixtures son válidas, que sí que es interesante.

Pues mira que Rabble y tú me caéis bien y creo que sabéis mucho, pero aquí estoy con Juan (que también me caéis bien y sabe): no creo que tenga sentido probar Rails, que ya viene con su batería de pruebas. Hacer un test que pruebe si en mi modelo está funcionando bien has_many y belongs_to parece un poco absurdo, pues ya sabemos que funcionan bien. Con, quizá, la única excepción del TDD, donde yo escribo el test que describe la funcionalidad que quiero, y luego hago pasar el test colocando el has_many y el belongs_to. Y con las validaciones obvias, pues lo mismo. Excepción hecha como tú has dicho del validates_format_of, donde realmente sí escribimos código de nuestra cosecha, aunque sea una expresión regular (ja!). Obviamente sí hay que testear nuestro código del modelo, tanto nuestras validaciones, como nuestros callbacks, como cualquier método que añadamos.

Otra excepción cuando a lo mejor sí que podemos testear código de Rails (sigo con el ejemplo de las relaciones), es cuando estas relaciones son suficientemente complejas como para poder no estar seguro de haber puesto las llamadas adecuadas en el modelo adecuado y con los parámetros adecuados. Si, por ejemplo, mezclas polimorfismo con herencia simple y con algún :through, ahí puede ser bueno testear porque es muy fácil haber metido la gamba. Pero no estás probando métodos de Rails, sino tú capacidad de usarlos de forma adecuada.

Wow! Pedazo de comentarios y cargados de razón.

Sin embargo, en mi defensa quiero alegar que para mí comprobar que mi modelo no duplica un atributo que le he indicado que no duplique no es testear Rails, sino comprobar que cumple con su especificación.

Rabble creo que habló durante la charla, o si no antes, de utilizar los tests de Rails como una especificación funciona y cerrada que debería de cumplir nuestra aplicación. Algo así como el contrato. Si nuestra aplicación pasa los tests significa que por nuestro lado hemos cumplido.

Por supuesto que no pretendo testear Rails, que seguro que funciona muy bien, sino más bien asegurarme de que lo que estoy intentado implementar sea que lo tengo pensado.

Yo soy aún über-newbie en Rails, pero en esto estoy con Blat: no se trata de testear Rails, sino el modelo. Supongo que esto toma especial importancia con la desnormalización, aunque no se si Rails proporciona mecanismos automáticos para esto, ya digo que soy novatillo :-)

También creo que los test de unidad no deben aplicarse únicamente al modelo, Supongo que igualmente se deben probar unidades de software que sean mínimamente complejas (aserciones relacionadas con las requests en controladores, por poner un ejemplo).

Ya lo dije hace días cuando hablé de tests de unidad en Rails y hoy me reafirmo: ¡testea tus fixtures...

Pos anda que no tiene años este post ni na, pero lo acabo de encontrar hoy, cosas de la vida.

Y lo mismo ahora que las fixtures están pasadas de moda ya no tiene importancia, pero me ha parecido que ese test_fixtures es una buena práctica, que de hecho me ha permitido limpiar mis fixtures, que había alguna incoherencia por ahí suelta.

Ahora bien, puede haber casos en los que nos tengamos que saltar alguna comprobación de fixtures, porque como el conjunto de fixtures representa el estado de la aplicación en un momento dado, cuando tenemos modelos que mediante un before_create crean otros modelos dependientes, cuando verificamos la validez de unas fixtures, ¿en qué momento las estamos validando? Si al crear un objeto de clase A se le crea otro de clase B dependiente, ¿debo incluir en mis fixtures los correspondientes Bs a los As declarados en las fixtures? yo creo que si, pero entonces si en los A tuviéramos una validación de que no haya Bs relacionados, ya no validarían. O sea, la validación de las fixtures de A dependerá de si existe o no las fixtures B.

Toma paja mental. Supongo que la solución es "testea tus fixtures mayormente", pero siempre hay que adaptarse al escenario.

La verdad es que depende de cada caso: también es raro tener unas fixturas que incumplan algunas validaciones, pero bueno, no estaría mal, no?

Ahora la moda es no usar fixtures y usar escenarios...

La idea de este post era, intentar detectar mal funcionamientos en tus tests por culpa de unas fixturas mal hechas. Al fin y al cabo los tests también son código, y por tanto, ¿se puede testear, no?

Saluti!

Pues si, de hecho mirándolo mejor quizá son mis validaciones para este caso de A crea a B las que están mal... debería tener en cuenta este estado, en plan "no repitas B si eres un nuevo A, pero hombre no te quejas de que existe ya tu propio B, a ese no le cuentes :P" Así las fixtures seguirían representando un estado válido.