Testing y Métodos Privados

El otro día me asaltó una duda, ¿cómo se prueba un método privado?
Se me ocurrieron 2 soluciones, una no hacer el método privado y otra
llamarlo utilizando send (que se salta la visibilidad).
Al final lo resolví utilizando send.

Ahora investigando por Internet he leido varios artículos [1], [2] y
[3] (son relativos a Java pero las ideas son similares).

Me asalta una nueva duda: ¿es necesario probar los métodos privados?

Dede el punto de vista de una clase ya implementada podría ser
discutible que no se necesitan probar ya que son
utilizados desde las funcionalidades públicas y son estas las que se
deberían probar.

Desde el punto de vista TDD seguramente implementaré antes el método
privado que el método público que lo invoca
por lo que me gustaría asegurarme de que el método público funciona
correctamente. En este caso sí que le veo todo el sentido
a poder probarlo.

¿Alguna idea?

[1] - http://www.artima.com/suiterunner/private.html
[2] - http://beust.com/weblog/archives/000303.html
[3] -
http://fishbowl.pastiche.org/2003/03/28/testing_private_methods_dont_do_it

El 6/02/08, Víctor Martínez [email protected]
escribió:> El otro día me asaltó una duda, ¿cómo se prueba un método privado?

Se me ocurrieron 2 soluciones, una no hacer el método privado y otra
llamarlo utilizando send (que se salta la visibilidad).
Al final lo resolví utilizando send.

Me asalta una nueva duda: ¿es necesario probar los métodos privados?

Desde mi humilde opinión y así a bote pronto, yo apostaría porque un
método privado no debe ser probado. Yo creo que no deberían ni
aparecer en los diagramas de clases

Bastaría con probar los métodos públicos que lo usan.

Sería como probar una porción de código dentro de un método, pues no
viene a ser más que eso. Un método privado puede existir y luego
desaparecer sin que la función de la clase, desde el exterior, se vea
repercutida.

Igual mañana pienso otra cosa, pero hoy esta es mi opinión :slight_smile:

f.

2008/2/7 Fernando G. [email protected]:

Desde mi humilde opinión y así a bote pronto, yo apostaría porque un
método privado no debe ser probado. Yo creo que no deberían ni
aparecer en los diagramas de clases

Bastaría con probar los métodos públicos que lo usan.

El problema es que el testeo indirecto por medio de los métodos
públicos no es muy exhaustivo. Personalmente, suelo hacer protegidos
ciertos métodos que deberían ser privados (no todos) cuando sé que me
pueden dar problemas. Como bien dices, puedes alcanzar lo mismo con
send.

De todas formas, la mayoría de los métodos privados que
estarásescribiendo seran pequeños helpers que casi nunca necesitaran tests.

2008/2/6 Víctor Martínez [email protected]:

Dede el punto de vista de una clase ya implementada podría ser
¿Alguna idea?
En general los metodos privados (o protected) que uso son para ser
llamados con callbacks, estos si los testeo, ya que es “facil”
testearlo porque hago la transicion donde se llamaria el callback y
veo que ocurran los efectos que deberian ocurrir.

Tambien los metodos privados que son validaciones, estos claro que los
voy a testear.

En realidad testearia todo, tal vez no llamando al test directamente
pero sabiendo que el efecto que deba producir lo este haciendo
correctamente, despues de todo testeamos funcionalidades no codigo.

Salu2

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs