Pregunta

ActiveRecord::Base tiene una gran API con múltiples métodos para buscar y guardar objetos.Por ejemplo, tu AR::B Es posible que se hayan creado instancias de objetos a partir de varios métodos:

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

De manera similar, el objeto en cuestión podría persistir mediante 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 descartar las llamadas a métodos externos para que la prueba pueda centrarse en la lógica empresarial del método en cuestión.Sin embargo, cuando se trata de trabajar con AR::B objetos, por ejemplo en pruebas unitarias de controladores, parece que tienes que comprometerte con uno de los métodos anteriores, cuando en realidad, en lo que respecta a la lógica de negocios del método, no debería ser importante cuál elijas.

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

¿Fue útil?

Solución

Un enfoque es crear sus clases de tal manera que concluya cualquier ActiveRecord::Base llamadas a métodos en sus propios métodos.

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

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

De esa manera, en sus pruebas, puede eliminar sus propios métodos en lugar de los de ActiveRecord.

Avdi Grimm describe en detalle este enfoque (incluidos sus beneficios) en el libro 'Objects On Rails'... http://objectsonrails.com

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top