[Unit Tests] Contras de implementar test unitarios

He querido compartir en este video de 7 minutos mis experiencias con la implementación de test unitarios cuando la inversión en capacitación es escaza. Que peligros encierra una pobre capacitación y ante que escenario nos podemos encontrar es de los objetivos de este video.

 

 

Lucas Ontivero

Sin categoría

6 thoughts on “[Unit Tests] Contras de implementar test unitarios

  1. Estoy deacuerdo contigo, crear test unitarios de calidad requiere una alta capacitación y no te digo nada si encima utilizas mock objects y otras utilidades. No todo es de color de rosa…

    Un Saludo.

  2. Lucas, con todo el respeto, no entiendo el punto del video.

    Escribir test es escribir código, como todo código es un código con una especialidad, validar otro código.

    Como cualquier código se puede hacer bien o mal, se puede respetar una convención o no, los tests pueden ser coherentes y homogeneos o no, pueden tener una nomenclatura común o no y hay buenas prácticas que se conocen o no. Nada diferente a escribir otro tipo de código: acceso a datos, ajax, wpf o lo que sea…

    ¿Alguien haría un video titulado ‘Contras de hacer código de acceso a datos’?

    No hay contra alguna. Hacer tests es radicalmente bueno. Punto. Que nadie se quede con otra copla. Incluso es preferible tener malos tests que no tenerlos en absoluto. Creo que con tu video estás dando una cohartada a la gente floja que dice, como hacer tests se puede hacer mal no lo hago y punto.

    Sobre tener más test que código de producción es imposible, observar la cobertura te protege de esto. Igual que te proteje de otras anomalias.

    Sobre la capacitación, de acuerdo, pero el testeo unitario no es ‘rocket science’, no hay mucho secreto. En 3 horas, se pueden tocar todos los temas que comentas, a partir de aquí: A andar se aprender andando.

    Quien tenga dudas que repase la mágnifica serie de artículos sobre el tema de nuestro vecino de blog Ibon Landa:
    http://geeks.ms/blogs/ilanda/archive/2009/06/16/pruebas-unitarias-resumiendo.aspx

    ¡Un saludo!

  3. @Juan, me alegra que pienses parecido.

    @Rodrigo, desde mi punto de vista y según mi experiencia, escribir test unitarios no es como escribir código. Es cierto, es código, pero muy distinto al de producción. Demasiado distinto!

    Por otro lado, puedo aceptar la crítica del título porque este no representa bien la idea detras del video pero bueno, es válida tu crítica en este aspecto.

    «No hay contra alguna. Hacer tests es radicalmente bueno. Punto.» Bueno, aquí si que no puedo estar de acuerdo, sería esta la única cosa sin contraindicaciones de la que haya oido en mi vida. Que nadie ponga en duda una práctica, aún cuando alquien trata de advertir sobre algunos riezgos, no es saludable. No deben existir tabues, ni dogmas en aquí. No existen las balas de plata.

    El dicho «es preferible tener malos tests [unitarios] que no tenerlos en absoluto» es bien conocido pero desgraciadamente no lo creo así. Tener malos test significa invertir el algo cuyo retorno es bajo y por lo tanto no puede ser una buena idea nunca.

    Sin dudas que tanto los tests como todas las cosas se pueden realizar con distintos niveles de correctitud pero no por eso se deben dejar de hacer. Yo, por ejemplo, hago un café muy feo, casi siempre, y no por eso dejo de hacerlo por las mañanas. Ya estoy mejorando. Pero bueno, la gente floja no necesita que nadie invente excusas por ellos. Yo no estoy dando excusas, estoy proponiendo *soluciones*: ser serios, capacitar y aprender. Ese es el fin del video. ¿Que puede estar mal con una recomendación tan básica?

    ¿Es imposible tener más código de tests que de producción?. No, no es imposible. Dificil tal vez pero no imposible. Pero eso es un tanto anecdótico, a lo que me refiero en el video es a grandes cantidades de tests unitarios.

    Yo estoy en contra del clásico training de 3 horas, eso solo alcanza para ‘vender’ la práctica y para nada más. Roy Osherove, según sus palabras, tardó tres años en escribir su libro (recomendable). Todo un libro, ¿se podrá reducir a 3 horas?. NO! con 3 horas obtienes el tipo de problemas sobre el que estoy tratando de advirtir!

    Para cerrar, a todo aquel que piensa incorporar esta práctica, solo puedo decirle que invierta en capacitación ya que el esfuerzo que consume su creación y mantenimiento van a salir de su bolsillo. Invertir en capacitación es reducir riezos y asegurarse cierto retorno.

    Yo propongo como referencia obligada el libro «the art of unit testing», los video de Roy Osherove y los post the Jeremy Miller y los de Martin Fowler.

    Saludos.

  4. Lucas, totalmente de acuerdo en lo de formarse. Es vital.
    Sigo pensando que no debes pagar a nadie más de tres horas por aprender testeo unitario. Si el bueno en ese tiempo te forma en lo necesario. Luego evidentemente, como en todo, hay que leer y practicar para mejorar.

    Evidentemente cuanto más capacitado estes en lo que sea mejor.

    Todo se puede convertir en un problema pervirtiendolo hasta la saciedad. Pero hacer tests, es como beber agua, esencialmente bueno. Eso si si te bebes cien litros o te la bebes con sal te mueres. Pero insisto, hay que animar a todo el mundo a que use testeo unitario. Es bueno tener tests, buenísimo. ¿O no estás de acuerdo?. La gente que tiene tests y que tiene problemas con ellos, que los refactorice, como cualquier otro código.

    Por último, no he dicho que es como escribir cualquier código, es un código especializado en una labor y con ciertas particularidades, pero código al fin y al cabo. Y hay que mantenerlo, refactorizarlo y cuidarlo como el resto del código de la aplicación.

    Una última pregunta ¿no crees que es mejor que todo el mundo escriba tests? ¿no crees que tenemos que evangelizar y no asustar al respecto? ¿no crees que solo escribiendo tests se mejora como se escriben tests? Puedes leer ad infinitum, como no te pongas a hacer tests en la vida harás buenos tests. El objetivo es ¡NI UN SOLO PROYECTO SIN TEST UNITARIOS! y creo que tu video nos aleja de ese objetivo por que crea incertidumbres y no las resuelve.

    ¡Un saludo!

  5. Rodrigo, sí, hay varios temas en cada comentario tuyo y en cada respuesta mía por lo que no quiero irme mucho del tema que intento tratar, pero voy a contestar tus preguntas para que se aclaren mis intenciones.

    1. Los UT no son buenos per se, son buenos en la medida que ayudan al desarrollo del producto. Los malos tests no ayudan mucho, solo cuestan. Pero sí, si los haces medianamente bien son buenísimos. De acuerdo.

    2. ¿no crees que es mejor que todo el mundo escriba tests? Creo que sería muy bueno que todo el mundo escribiera tests.

    3. ¿no crees que tenemos que evangelizar y no asustar al respecto? No y no, yo no quiero evangelizar, yo quiero compartir experiencias y machacar con la capacitación. Los beneficios de escribir test los encuentras en todas partes. ¿Cual sería mi aporte si dijera «escribir tests es muy bueno»?. Cuanto bien le hubiese hecho a muchos equipos el ver un video como este antes de lanzarse como locos animados por algún evangelizador que siempre cuenta la parte linda.
    El otro ‘no’ es porque yo no intento asustar, animo a pensar y a invertir (tiempo) en capacitación. Si alguien se asusta y eso le ayuda, bienvenido.
    A mi me pasa todo el tiempo, cada vez que doy una charla la gente me mira como diciendo..»pero entonces, esto no resuelve todos nuestros problemas?», «como? tengo que pensar cada vez que quiero hacer algo?», «me estas diciendo que con esta charlita de morondanga no nos alcanza?» y cosas por el estilo. Y es que realmente la magia no existe. Pero a los evangelizadores se los despiden agradecidamente por haberles mostrado la luz.

    4. ¿no crees que solo escribiendo tests se mejora como se escriben tests?. Esta pregunta es muy buena porque es compleja de responder. Pienso dos cosas con respecto a esto: la práctica sin teoría no enseña nada y, la teoría sin la práctica tampoco. Creo que hay que estudiar y echar manos a la obra, luego equivocarnos y descubrirlo rápido entonces volver a leer, pensar, corregir los errores y nuevamente manos a la obra. Aquí hay dos punto, estudiar es primero (no 3 horas), luego poder descubrir que estamos haciendolo mal rápidamente y estudiar como resolverlo.

    Bueno, esas son mis respuestas. Ahora, déjame hacer un comentario sobre tu última oración. No es mi objetivo el que todos los proyectos tengan tests unitarios, me gustaría pero no es mi objetivo. Tampoco ha sido mi objetivo el desalentar su implementación, esa es solo una interpretación personal tuya. Ahora, ¿crea mi video incertidumbres?. Puede ser! duden!, no es malo pensar ni dudar. Investiguen, crucen opiniones con gente que se haya equivocado mucho y haya aprendido. Si dudan van a intentar quitarse esas dudas LEYENDO. Pero no leyendo solo la parte bonita, busquen que debe existir algo más. Busquen!

    Por último, es totalmente cierto, mi video no resuelve las dudas que plantea. Es un video de 7 minutos que no persigue ese objetivo, persigue otro que ya expuse. Resolver esa incertidumbres escapa al objetivo del video y jam’as se podrían resolver en 7 minutos, ni en 10, ni en 1 hora. Pero para quien quiera las respuestas, las respuestas están disponibles en el libro «the art of unit testing» de Roy Osherove y sus videos.

    Saludos!

  6. Totalmente de acuerdo. Hacer test es bueno …. si se hacen bien. Si se hacen mal, al final aportan muy poco y dan más trabajo. Y desgraciadamente, en la realidad, lo normal es irse a la segunda opción.

    Sí, es muy importante la capacitación y la experiencia, pero la descripción de tu blog «Sigo pensando todo de nuevo mil veces y todavia encuentro mejores maneras de hacer lo mismo. Creo que ya tenemos todas las soluciones al igual que lo creia 8 años atras.» sigue expresando muy bien la realidad:

    – La gente competente siempre está aprendiendo, tratando de no tropezar en la misma piedra por segunda vez.
    – Los demás se empeñan en romper la misma piedra a base de darle cabezazos y nunca mejoran, o lo hacen muy poco.

    Hay que hacer test y hay, sobre todo, que aprender a hacerlos. Y el camino no es de rosas.

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *