Mockist TDD para validar campos antes y despues del save


#1

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.


#2

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:

  1. 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.
  2. 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] http://gist.github.com/56996
[2]
http://blog.jayfields.com/2006/12/rails-activerecord-unit-testing.html


#3

On Mon, Feb 2, 2009 at 6:04 PM, alarkspur removed_email_address@domain.invalid wrote:

end

end


Ror-es mailing list
removed_email_address@domain.invalid
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 > removed_email_address@domain.invalid
blog > http://www.lacoctelera.com/porras
now > http://twitter.com/porras


#4

El día 2 de febrero de 2009 19:14, Sergio Gil Pérez de la Manga
removed_email_address@domain.invalid
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.


#5

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