Por qué no deberías escribir pruebas unitarias [Actualizado]

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.

18 comentarios en “Por qué no deberías escribir pruebas unitarias [Actualizado]”

  1. Esto hay que leer se lo sin respirar, para que tenga sentido.

    Hay un punto de que se habla el articulo. La reescritura de las pruebas unitarias cuando se cambia la libreria que prueba. No esto un, un sintoma de que hay algo mal hecho. Las pruebas unitarias sirven para asegurarnos de lo que funciona, siga funcionando. Así que si se modifica una libreria para meter le más funcionalidad, la funcionalidad antigua deveria seguir funcionando. Así que la prueba unitaria antigua no se deberia de tocar.

  2. Si algun organismo como la NASA, la BMW o la BOEING dicidieran como Luis Guerrero, que todo lo que hacen siempre va estar bien y que no necesitar asegurar nada de calidad, depronto seriamos neardentales que no necesitariamos computadoras.

  3. Leamos mejor el post de otra forma, todo lo que dice son el fundamento de porqué hacer PRUEBAS UNITARIAS. Jejejeje.

    Saludos.
    Francisco J.

  4. Lo importante en la construcción de software son las personas. Las herramientas importan,Las técnicas también importan,Los procesos importan,Pero por sobre todas estas cosas que importan están las personas.
    Los grandes desarrolladores crean gran software no porque siguen las reglas de alguna metodología, sino porque son ingenieros verdaderamente capaces.

Deja un comentario

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