@ernesto: Interesante propuesta. Aunque no le acabo de ver utilidad xD, no sirve ni como la “alarma” de la que habla Fernando ni como la “guía para implementar” de la que habla Juanjo. Sin embargo, sí que sirve para apoyar mi argumento: si podemos llegar a automatizar la generación de la implementación a partir del test o, incluso como tú demuestras, el test a partir de la implementación, entonces es que algo falla, no?

@juanjo: Incluso el escenario que propones en el que una persona escribe el test/especificación y otro la implementación creo que tiene más sentido a nivel de integración que a nivel de unidad.

La útilidad de alerta que menciona Fernando creo que en la práctica desaparece y esos tests en general casi no sirven ni para avisar de que la implementación ha cambiado porque lo primero que va a hacer el programador que borre un validate_presence_of es ir y borrar el test correspondiente. Estamos utilizando un test para explicitar que las lineas de código en las que se establecen relaciones son importantes y no hay que borrarlas, pero eso debería ser obvio.

Sin embargo sí creo que hay algun caso en el que esos tests son útiles, por ejemplo: en un desarrollo BDD puro en el que los tests se escriben antes que el código las especificaciones de los modelos pueden ser directamente los tests, escritos potencialmente por una persona distinta de quien se encargará después de la implementación.
En ese caso sí son útiles los tests sobre validaciones o relaciones, aunque más como guía o requerimientos previos que como chequeo de correcto funcionamiento.

Limitaciones, si tienes alguna clase de tests de modelo que no deriva de Test::Units los tests cascarán.

Si alguien quiere meterle mano al plugin ya tiene un primer comienzo ;)

Un saludo!

Las relaciones no las testeo prácticamente nunca (si se pierde un belongs_to, saltará en cualquiera de las decenas de tests que lo usan), y puestos a testearlo, testearía que el modelo proporciona la interfaz de la relación, no la relación en sí (de eso ya se encargan los tests de AR)

Sobre las validaciones, eso ya es otro cantar. La cuestión de testear las validaciones viene del concepto de “fat models” donde tenemos controllers que prácticamente no hacen nada.

e.g:

def create
  @post = Post.find(params[:post_id])
  @comment = @post.comments.build(params[:comment])
  
  if @comment.save
    notify :notice, 'Comment added'
  else
    notify_errors @comment
  end
end

Como ves, toda la carga de la validación cae sobre el modelo, con lo que deberíamos testear esa parte.

Lo que sí que creo es que quizá cabría hacer una mejor refactorización para testear los validadores (y asociaciones). Dicha refactorización consistiría en no escribir esos tests, sino que el framework identificase las validaciones y crease los tests por metaprogramación.

Algún día quizá intente hacer el auto_testeado, al fin y al cabo, lo que estamos haciendo con shoulda es repetir lo que ya hemos escrito en el modelo :)

En mi opinión la diferencia entre escribir tests unitarios sobre la parte declarativa sí que tiene sentido por una razón:

si tu modelo post no estuviera relacionado con un usuario, ¿tu modelo seguiría siendo correcto? ¿o debería de haber algo que hiciera saltar una alarma y dijera: “esto no está bien, tiene que existir un usuario asociado al post”?

No sé si el lugar para definir esa “alerta” es un test de unidad, porque de teoría controlo bastante poco, pero a mí no me parece mal sitio, ¿no?