Forum: Rails-ES Mockist TDD para validar campos antes y despues del save

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
94ac01209314464490a94b47f051be0b?d=identicon&s=25 alarkspur (Guest)
on 2009-02-02 17:58
(Received via mailing list)
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.
348246701cfdb2130b842fd839751a18?d=identicon&s=25 Raul Murciano (raul)
on 2009-02-02 18:40
(Received via mailing list)
> 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-activereco...
45742831d67c80d12cd7b24907b8d760?d=identicon&s=25 Sergio Gil Pérez de la Manga (Guest)
on 2009-02-02 19:14
(Received via mailing list)
On Mon, Feb 2, 2009 at 6:04 PM, alarkspur <alarkspur@gmail.com> wrote:
>     end
>   end
>
>
>
>
>
> _______________________________________________
> Ror-es mailing list
> Ror-es@lists.simplelogica.net
> 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 > sgilperez@gmail.com
blog > http://www.lacoctelera.com/porras
now > http://twitter.com/porras
348246701cfdb2130b842fd839751a18?d=identicon&s=25 Raul Murciano (raul)
on 2009-02-02 19:28
(Received via mailing list)
El día 2 de febrero de 2009 19:14, Sergio Gil Pérez de la Manga
<sgilperez@gmail.com>
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.
94ac01209314464490a94b47f051be0b?d=identicon&s=25 alarkspur (Guest)
on 2009-02-02 22:08
(Received via mailing list)
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 Murciano
escribió:
>> Logicamente el test pasa, se graban los datos y se comprueba luego
This topic is locked and can not be replied to.