Hola
En un modelo como el siguiente
class Post < AR
validate_presence_of :title
before_save :create_slug
private
def create_slug
self.slug ||= self.title.gsub(’ ‘,’-’).downcase
end
end
un test podrÃa ser algo como
describe Post do
before(:each) do
@post = Post.new :title => “First post”
end
it “should have a integer in created_at_reverse” do
@post.save
@post.slug.should eql(“first-post”)
end
end
Logicamente el test pasa, se graban los datos y se comprueba luego que
el campo slug sea el deseado, pero… Si se desea al ser un test
unitario que este no dependa de la base de datos ¿como se comprobarÃan
los metodos que se ejecutan de la llamada a un callback x? ¿Es posible
mockear un save?
Gracias por la info.
Saludos.
Logicamente el test pasa, se graban los datos y se comprueba luego que el
campo slug sea el deseado, pero… Si se desea al ser un test unitario que
este no dependa de la base de datos ¿como se comprobarían los metodos que se
ejecutan de la llamada a un callback x? ¿Es posible mockear un save?
He hecho una pequeña prueba[1] y parece que, seguramente por cómo está
implementado en AR el sistema de callbacks, al mockear el save no se
ejecuta el before_save. Como al final save termina haciendo un create
o un update puedes optar por mockear esta llamada para evitar esa
escritura en la base de datos.
De todas formas AR necesitará acceder a la base de datos para algo
másque ese save (por ejemplo lee las columnas de la tabla posts ara
comprobar los atributos de los objetos de la clase Post), así que por
ahí veo dos opciones:
- usar una base de datos mínima para tus tests, como la que gestiona
rails al hacer los tests. En mi ejemplo he usado una ad-hoc para este
test.
- mockear todo lo relacionado con la base de datos:
conexión,llamadas, etc. Personalmente me parece incomodísimo, Jay Fields
escribió algo sobre este tema[2]
[1] 56996’s gists · GitHub
[2]
Jay Fields' Thoughts: Rails: ActiveRecord Unit Testing
On Mon, Feb 2, 2009 at 6:04 PM, alarkspur [email protected] wrote:
end
end
Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es
Hombre es que si realmente quieres hacer un test de unidad en el
sentido purista del término (y el no acceso radical a base de datos es
bastante purista), lo lógico es que lo que testees sea el método que
hace de callback, y no que se llama al mismo:
describe Post do
before(:each) do
@post = Post.new :title => “First post”
end
describe “create_slug” do
it “should set the slug” do
@post.create_slug
@post.slug.should eql(“first-post”)
end
end
end
o algo así
La verdad es que para este caso veo más práctico permitir el acceso a
base de datos porque este test que he escrito es un poco sin sustancia
(aunque si la lógica del método fuese más compleja,
quizás sí tendríamás sentido).
–
Sergio Gil Pérez de la Manga
e-mail > [email protected]
blog > http://www.lacoctelera.com/porras
now > http://twitter.com/porras
El día 2 de febrero de 2009 19:14, Sergio Gil Pérez de la Manga
[email protected]
escribió:> Hombre es que si realmente quieres hacer un test de unidad en el
sentido purista del término (y el no acceso radical a base de datos es
bastante purista), lo lógico es que lo que testees sea el método que
hace de callback, y no que se llama al mismo
+1, sólo añadir que (salvo que RSpec aporte algo al respecto, que no
lo sé) tendrías que usar algún pequeño workaround porque en este caso
el método que testearías es privado.
Muchas gracias a ambos por los consejos y enlaces, han sido muy utiles
para poder continuar con “esto” del testing.
Muy amables. Gracias.
Saludos.
El 02/02/2009, a las 18:40, Raul M.
escribió:
Logicamente el test pasa, se graban los datos y se comprueba luego