Reconozcámoslo escribir pruebas unitarias no sirve para nada. No sirve para nada porque tenemos que además de hacer nuestro trabajo de desarrollar software de calidad tenemos que escribir código que pruebe que testee nuestro código. Además para que las pruebas las podamos crear de manera cómoda y centrarnos en la palabra unitaria tenemos que hacer que nuestro código sea fácilmente aislable porque claro, como vas a hacer una prueba unitaria si para llamar a un método de una clase tienes que llamar a 300 factorías para crear una instancia de una clase, es un coñazo. Y conforme el proyecto avanza debemos mantener las pruebas cuando los métodos que estamos testeando hayan cambiado (otro coñazo), en definitiva tenemos que tirar el tiempo en algo que definitivamente no sirve para nada.
Y fijaros si no sirve para nada, que yo en mis desarrollos no utilizo pruebas unitarias, yo siempre que escribo código estoy seguro de que lo he escrito está bien y siempre va a funcionar de la misma manera. Siempre. Porque no os equivoquéis, si no escribo test unitarios, porque estoy seguro de lo bien hechas que están mis clases, es porque mis clases son un ejemplo de diseño SOLID, utilizo los patrones con moderación y me hecho aficionado a la inversión de control.
Para qué escribir pruebas unitarias si está claro que lo más importante de un proyecto es .NET y como yo en mi proyecto estoy usando la última beta de acceso de datos de Entity Framework mi proyecto está claro que saldrá bien porque con que ejecute un par de veces mi aplicación, haga un par de clicks sobre algunos botones y haga un par de consultas a la base de datos a través de WCF, quien va a necesitar testear contantemente el código de nuestra aplicación si para nada el desarrollo de software es una de las disciplinas más complejas y con mayor grado de abstracción de toda la historia del ser humano. Nadie. Es más ningún proyecto falla por la gestión del proyecto siempre por la tecnología, por eso hay siempre que usar últimas versiones.
Además los ordenadores siempre ejecutan el código de la misma manera, a quien le ha pasado alguna vez que desarrolla el software en su máquina lo ejecuta en un pc del mismo modelo con la misma versión de Windows y el software no funciona. A nadie.
Es por eso que yo hace tiempo que decidí no utilizar pruebas unitarias en mi desarrollo día a día, tampoco utilizo compilaciones automáticas, ni tampoco utilizo metodologías de desarrollo agiles, pues total siempre acabo los proyectos bien.
Además tampoco estoy pendiente de los mensajes que escribe la comunidad porque para nada llevo escuchando desde hace mucho tiempo que las pruebas unitarias están bien, porque claro cualquiera puede escribir lo que quiera, fíjense en mí que estoy diciendo que sin hacer pruebas unitarias todo el desarrollo de mis proyectos ha ido siempre bien. Yo estoy bien como estoy.
Luis Guerrero.
Modo ironia OFF
Atualización 9/4/2011
Parece
que algunas personas no han entendido el significado del post viendo los
comentarios y Twitts, el post está escrito con ironía para así recalcar lo
importante que son las pruebas unitarias en el desarrollo de software. Y cuando
me refiero a testing unitario no solo me refiero a ese tipo de testing, me
refiero a testing de integración, tesing manual y demás formas de testing.
Yo
personalmente programo mucho en la parte de Interfaz de usuario con Silverlight,
y tengo que decir que escribir pruebas unitarias de código de UI de Silverlight
(no confundir con testear el ViewModel) es complicado. Se están dando avances
por parte de Microsoft para hacer que se pueda testear el código de la UI pero aun
así sigue siendo complicado.
Mi
amigo Vicente Cartas ha escrito un artículo que se llama “Por qué no deberías
probar lo que desarrollas” que justamente viene a decir lo mismo pero poniendo
otro tipo de ejemplos y muy centrado en el testing manual. Es un artículo de
lectura obligada.
P.D. al
final del articulo hay un texto que pone Modo Ironia OFF pero que tiene un
color de fuente blanco así que si seleccionáis con vuestro navegador el texto veréis
que esta hay desde el principio.