2012-03-15 16 views
8

ActiveRecord::Base tiene una gran API con múltiples métodos para buscar y guardar objetos. Por ejemplo, sus AR::B objetos podrían haber creado instancias de una serie de métodos:¿Cómo se guardan los métodos de ActiveRecord :: Base sin hacer suposiciones acerca de cómo se usa?

  • Foo.new(…)
  • Foo.create(…)
  • Foo.find(…)
  • Foo.find_by_sql(…)
  • Foo.find_[all_]by_*(…)
  • bar.foos (asociaciones)
    • ... y buscador de métodos en asociaciones, por supuesto

Del mismo modo, el objeto en cuestión puede ser que consiga persistido por algunos métodos diferentes:

  • foo.create o foo.create!
  • foo.save o foo.save!
  • foo.update_attributes o foo.update_attributes!

Ahora, al escribir pruebas unitarias, es una buena práctica anular las llamadas a métodos externos para que su prueba pueda enfocarse en la lógica comercial del método en cuestión. Sin embargo, cuando se trata de trabajar con objetos AR::B, por ejemplo, en pruebas de unidades controladoras, parece que tiene que comprometerse con uno de los métodos anteriores, cuando en realidad, en lo que respecta a la lógica comercial del método, no debería ser importante que elijas.

¿Tiene que unir el comportamiento de su método tan estrechamente con su implementación o me falta algo simple?

Respuesta

3

Un enfoque es construir sus clases de tal forma que finalice cualquier llamada al método ActiveRecord::Base en sus propios métodos.

Así que en lugar de llamar directamente Foo.new(…) ...

class Foo < ActiveRecord::Base 
    def self.create_object(…) 
    new(…) 
    end 
end 

De esta manera, en las pruebas que pueden apagar sus propios métodos en lugar de ActiveRecord de.

Este enfoque (incluyendo sus beneficios) se describe en detalle por Avdi Grimm en el libro 'Objetos On Rails' ... http://objectsonrails.com

Cuestiones relacionadas