entre Desarrolladores

Recibe ayuda de expertos

Registrate y pregunta

Es gratis y fácil

Recibe respuestas

Respuestas, votos y comentarios

Vota y selecciona respuestas

Recibe puntos, vota y da la solución

Pregunta

1voto

En el proceso de desarrollo de una funcionalidad en el sistema se generó un método publico llamado TransferenciaBancaria, el cual consistia en transferir monto de un cuenta a otra. Para ello, se implemento internamente 2 métodos privados, de los cuales no se le hizo pruebas unitarias, sino se aplico la prueba unitaria solo al principal TransferenciaBancaria, por tanto se dijo que no se estaba aplicando TDD completamente, esto es cierto?. En TDD sino generó todas las pruebas unitarias para métodos privados no es TDD?

1 Respuesta

1voto

Leonardo-Tadei Puntos227320

Hola Alberto,

puede ser cierto...

Cuando hacés TDD, se suponen algunas cosas y otros son reglas a cumplir.

Una regla a cumplir es el porcentaje de cobertura del código que te piden. Lo sensato es pedir alrededor de un 70% de cobertura del código ejercitado por los test. Esto se da siempre en el contexto en que el cliente es quien escribe los test, o al menos un equipo independiente del equipo de desarrollo.

Por otra parte, no sé qué software de testeo estás usando, pero si tu método público funciona usando los métodos privados, estos métodos privados ya fueron cubiertos por el testeo y el analizador de cobertura debería mostrarte esto: sería una contradicción tener que volver públicos los métodos privados para testearlos, ya que por un lado deben hacer tareas pareciales que no tienen sentido sin el contexto del llamador, y por otro el modelo no debería nunca pedir que se violen lo sprincipios de POO.

Acá trabajamos mayoritariamente en PHP y PHPUnit muestra la cobertura del código, incluyendo lo que requirió llamar a métodos privados, siempre a través de la interfaz pública del Objeto. Se ve por ejemplo así: http://archive.typeoneerror.com/files/images/xdebug.jpg

Por último algunos supuestos: se supone que no tiene sentido testear los setters y los getters y otros métodos extremadamente triviales y es por esto que nunca se pide una cobertura del código del 100%.

Pero esto implica que, si trabjando se descubre que algún método relevante para el Modelo no está ejercitado por los test que te dieron, deberías escribir un test para ejercitarlo, dándole así sentido completo a la TDD.

En resumen, aplicás TDD bien si tu código pasa todas las pruebas que et dieron y si agregaste pruebas de cosas relevantes que no estaban cubiertas originalmente. A su vez, creo que no se aplica correctamente TDD si sos vos el que escribe el código y los test: está abundamente demostrado que los test tienen que ser escritor por personas que no estén involucradas en la generación del código.

Saludos cordiales!

0voto

Leonardo-Tadei comentado

Hola @uialberto,

te sirvió la respuesta? Conseguiste alguna mejor para compartir con la comunidad?

0voto

uialberto comentado

Gracias Leonardo! Me ha servido para comprender mejor TDD, aunque en la practica muchas veces no se generá pruebas unitarias para todos los métodos internos! Encontes, si esto es asi, no se está aplicando TDD al 100%. Siempre que se generé pruebas unitarias para todos los métodos internos (y no solo los publicos) generados durante el desarrollo se puede decir que se aplica TDD al 100%. ?

0voto

Peter comentado

@uialberto converti tu respuesta en comentario porque no era una respuesta a tu pregunta :)

0voto

Leonardo-Tadei comentado

Hola Alberto,

no estoy seguro de que tenga sentido decir que se aplica una metodología como TDD o cualquier otra un 100% o un 72%... cómo se mide el uso de una metodología?

En el caso de TDD, sí podemos dar una medida objetiva de cobertura de código, que no es lo mismo. Como te decía en la respuesta, por un tema de costos es muy raro que se pida un 100% de cobertura, algo que además no tendría sentido, porque sería ridículo escribir test para probar setters y getters como el ejemplo más clásico.

En un supuesto en que los setters y los getters de las clases de un Modelo sean el 60% del código y el otro 40% sea el código que resuelve el problema, yo prefería un 40% de cobertura de ese código (que es el 100% del código que importa) y no un 80% de cobertura y que me dejes medio Modelo sin ejercitar por los test. Es un ejemplo extremo, pero ilustra bien el caso.

Diría que si probás el código que sí importa (que es el 40%) estás usando correctamente TDD, que es lo importante.

Respecto a lo que llamás "métodos internos", si te referís a métodos privados de las clases, estos no podrán ser testeados directamente porque no pueden ser invocados de forma directa. Sin embargo un buen test sería usar métodos públicos que para funcionar llamen a los privados: eso sería un excelente test.

En cambio si para probar un método privado le cambiás la visibilidad, sería un mal test porque estás probando un código que no es el mismo que estará en producción.

TDD son una serie de principios de desarrollo de software. Si usás estos principios, está bueno aplicarlos a conciencia, interpretando el espíruto de la idea y no mecánimente las cosas para mostrar un gráfico bonito de nuestras buenas prácticas.

Saludos cordiales!

0voto

uialberto comentado

Gracias Leonardo! Con esto doy por cerrado la pregunta.

Por favor, accede o regístrate para responder a esta pregunta.

Otras Preguntas y Respuestas


...

Bienvenido a entre Desarrolladores, donde puedes realizar preguntas y recibir respuestas de otros miembros de la comunidad.

Conecta