Lucas Ontivero

@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.

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!