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.
Joder, por fin, un tio con sentido común… 🙂
xDDD eres un figura!
Ahora esperate que antes o después te enlazaráon como post de porque no usar pruebas unitarias x)
Más claro, agua
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.
además para que usar .net si puedes usar lisp
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.
Tu problema es que no utilizas INTEGRACIÓN CONTINUA:
http://es.wikipedia.org/wiki/Integraci%C3%B3n_continua
No trabajas con un grupo de gente y con el código que picas te resulta suficiente. La gran utilidad de las pruebas unitarias es ejecutarlas cada 15-30 minutos sobre el código en el repositorio. Te ahorras infinidad de problemas cuando estás coordinando un grupo de trabajo.
Creo que hay gente que no ha pillado la Ironia XDD
Te ha faltado el
[Modo ironía = ON] Blabla [Modo ironía = OFF]
Hay quien no lo ha pillado
Churrasco, lo mejor es que el comentario de Ironia OFF esta en el post, solo hay que buscarlo 🙂
Leamos mejor el post de otra forma, todo lo que dice son el fundamento de porqué hacer PRUEBAS UNITARIAS. Jejejeje.
Saludos.
Francisco J.
Buaaaaaa, Luis Guerrero es un TECNICOLESS!!!
Ajajjaa, pruebas unitarias?
¿ Que es eso???
Completamente de acuerdo con tu post.
Saludos
^^ Cool :
XDDD
Pillado L. Yo tampoco las hago.
Un saludo!
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.
(I’m sorry this post is in Spanish, it’s related to a topic that has appeared recently in the Spanish
(I’m sorry this post is in Spanish, it’s related to a topic that has appeared recently in the Spanish