Publicado un nuevo número del podcast de javaHispano. En esta ocasión vamos a realizar una tertulia sobre test de aplicaciones. En este número participarán Alfredo Casado, Julio César Pérez y Jose Luis Bugarín. Dada la extensión del tema hemos dividido la tertulia en dos partes. En esta primera parte realizaremos una introducción a los test de aplicaciones, explicaremos para que sirven, clasificaremos los diferentes tipos de test que se pueden desarrollar, explicaremos buenas prácticas para que tu código sea testeable y finalmente hablaremos del desarrollo TDD.
Links de interés:
Etiquetas: otro, podcast, test
Madre mía, este es sin duda uno de los mejores podcasts que habéis hecho. Recomiendo a todo el mundo que se lo baje y lo escuche porque merece muchísimo la pena.
Y además con segunda parte, a ver con qué nos sorprendéis :-)
"En esta ocasión vamos a realizar una tertulia....."
Me podrian explicar ¿qué es una tertulia?
Para el anonimo, debe ser un palabro español que no se utilizan en paises hispanoamericanos. Desconocia que solo fuese español. Para futuros números intentaré utilizar otro término.
El significado es: Reunión de personas que se juntan habitualmente para conversar o recrearse.
Saludos, Jorge
deacuerdo con Raul, sin duda este es uno de los mejores podcast, yo por mi parte voy a escucharlo varias veces mas, muchas gracias a todos los participantes por sacar algo de tiempo para aportar tan valioso material.
saludos
soy de sudamérica y sé que es tertulia desde la escuela primaria.
Anonimo, gracias por la aclaración. Ya nos pasó en una ocasión el utilizar una palabra pensando que era universal y luego resultó ser solo en España. En ese caso, seguiremos utilizando la palabra Tertulia.
Saludos, Jorge
En américa del norte no se conoce la palabra tertulia, quizás en sudamérica si, como colombia y argentina, pero más al norte no se usa.
Enhorabuena por el podcast. Estoy de acuerdo. ¡De lo mejorcito! Estoy deseando escuchar la segunda parte. Los comentarios de Alfredo son realmente acertadísimos.
Sólo una cosita más. A los que estén interesados en TDD, hay una lista un poco "desanimada" a la que no le vendría nada mal gente que preguntara para que así la gente se animara a responder.
Enhorabuena de nuevo,
JMB
Hola chicos. Perdonad que use una noticia para algo de la web, pero es que he intentado contactar mediante el enlace homónimo y me dice que Imposible procesar la plantilla:FreemarkerTemplate: contactar/mailer/mailer.form.html Page: contactar/mailer/mailer.form.html. Expression directorio is undefined on line 39, column 28 in default/contactar/mailer/mailer.form.html.
Mi problema original es que estoy intentando registrarme, y tras introducir mis datos me lleva a la página http://www.javahispano.org/user.nuevo.action, en la que aparece completamente en blanco el apartado de contenido (el fondo y los menús se ven bien), y por título de página me muestra java.lang.Object@1cffc9b - Asociación javaHispano. Me imagino que además, debe de haber fallado el proceso de registro, porque ni me deja acceder con el usuario y password escogidos, ni he recibido correo alguno.
En cuanto al podcast, lo he estado escuchando esta mañana de camino al trabajo y ha sido uno de los que más me han gustado. Me temo que soy de los que usan la excusa del tiempo para no hacer pruebas más allá del "esto funciona, parece que esto va bien, clic por aquí, clic por allá...", así que voy a intentar poner en práctica alguna de las directrices presentadas en la tertulia.
Muchas gracias.
Seria interesante poner algunos ejemplos de JUnit y algunos ejercicios para que los podamos resolver. No sabria por donde meterle mano para empezar a hacer test.
Un saludo
Me alegro de que este gustando el podcast, queriamos meter muchas cosas en poco tiempo (así nos salieron dos xd), el objetivo de este primer podcast era sobre todo poner de manifiesto la enorme importancia de este tipo de tecnicas y animar a la gente a ponerse a la faena.
Para empezar con test hay multitud de ejemplos por ahí, por ejemplo el famoso bowling game de robert martin, buscando por la red encontraras un monton de cosas. Ya puestos recomiendo un par de libros importantes sobre el tema que no comentamos en el podcast:
- Test Driven Development by example de kent benck
- xUnit Test Patterns de Gerard mezaros
Muchas gracias por vuestros comentarios. Queriamos contar tantas cosas y a la vez que no quedará desorganizado ni excesivo, que era un poco difícil. Menos mal que Jorge, Alfredo y José Luis son unos cracks con los que fue un placer trabajar.
Podéis encontrar una buena introducción online a Junit con ejemplos básicos en castellano aquí.
Otro libro muy bueno es Pragmatic Unit Testing in Java with Junit.
Lo primero de todo fecilitaros por el podcast, pero un tengo mis duras respecto a los Test.
En principio estoy a favor de los Test y de hecho este año en clase (En un ciclo de FP) les estoy enseñando a los alumnos a que hagan test de integración con JUnit y test funcionales con Selenium y todo ello en un entorno de integración continua.
El problema de los Test es que hacerlos es demasiado complejo. Alfredo nos habla de sus experiencias positivas , pero yo no me veo al nivel de Alfredo y quizas muchos programadores tampoco.Que los beneficios son excelentes, si, pero creo que la dificultad también.
Muchas veces lo que triunfa en la empresa suele ser lo barato/facil/rápido y que aporte muchos beneficios. Pensemos en éxitos como el HTML y la Web, tuvieron éxito por lo facil que era hacer páginas web y los resultado extraordinarios que se obtenían con solo el bloc de notas y algo HTML. O el VB/Delphi, que facilitó mucho la programación respeto a usar el API de Window en el Visual C++. Otro ejemplo son los sistemas de control de versiones. Con 4 cosas que aprendas de subversion ya los puedes usar y el beneficio es enorme. Por poner un ejemplo , mis alumnos lo empezaron a usar en septiembre y dependen tanto de él que hasta querían usarlo en el examen.
¿Cuando tiempo/dinero puede costar formar a la gente para que puedan hacer Tests?¿Y cuales van a ser los beneficios? ¿Tenemos equipos de desarrollo con la suficiente calidad como para poder hacer Test aun habiendo sido formados?¿No habrá otra "idea" feliz que ayude a mejorar la calida del software de forma que hasta el más "tonto" de los informáticos se pueda beneficiar sin tener que ser un genio?¿No se puede mejorar mucho la calidad por ejemplo usando OpenXava o Ruby on Rails, etc.?¿ No hay otros caminos para acabar con la mala calida del software?
Para acabar,insistir en que la filosofía de la integración continua (CI) me parece genial. Cosas como compilar el código diariamente, desplegarlo diariamente, obtener métricas de calidad , etc, etc. Pero para hacer todo eso solo necesito a una persona que conozca esa tecnología , que me monte el entorno de CI y explicar al equipo de desarrollo como se usa. Pero hacer Tests es harina de otro costal,...
Saludos.
@logongas: respuesta rápida. El Testing tiene un ROI enorme. No sólo mejora la calidad del proceso de desarrollo, sino directamente la calidad del producto: Software con menos bugs. Pero el Testing no es el Camino. Caminos puede haber muchos, pero el Testing será una piedra básica en cada uno de ellos. Escribir un test suele ser sencillo, siempre que el sistema esté bien diseñado según los principios de acoplamiento y cohesión. Pero esto no es culpa del Testing...
Tu mismo has puesto un gran ejemplo. No todo el mundo abrazó el control de versiones a la primera. A algunos les costó -¿cuesta?- muchisimo. Cada día al menos un programador hace un commit infernal que rompe todo. Para usar control de versiones tienes que aprender nuevos conceptos, para programar tests lo principal ya lo sabes: programar.
Muchas de tus dudas serán resueltas en la 2a parte -espero-. Si quieres, y esto va por todos, puedes plantear algún ejemplo real de caso especialmente costoso de probar. Podéis subir algo de código (sólo interfaces) a algún servicio de publicación de código y hacemos una especie de taller muy rápido.
Hola logongas:
Lo primero si estas eneseñando a tus alumnos JUnit, selenium, integración continua, me parece fantastico, este es el camino precisamente y quiza uno de los mayores problemas por el que nos parece tan dificil hacer test es porque practicamente ninguno hemos recibido formación ni de pasada en este tema, y claro si piensas en diseño OO sin pensar en testing luego testear tu código es muy dificil o imposible, creo que de aqui vienen la mayoría de las dificultades.
Sobre el ROI del testing, según lo veo yo hay 3 opciones:
- probar a mano.
- probar automaticamente.
- no probar o probar superficialmente.
la primera no hay quien asuma el costo de probar a mano todos y cada uno los detalles de la aplicación cada vez que se modifica una parte, o eso o hacemos entregas cada x meses con lo que nos terminamos cargando la calidad de la aplicación, esta vez no por falta de test sino por falta de feedback del cliente.
La tercera opción es en la que están el 90% (y me quedare corto) de los proyectos actualmente en nuestra industria, con lo que la realidad es como contaba julio fantasticamente en el podcast, entregamos coches que se han probado metiendo primera y avanzando diez metros... y ale, listo!, como profesionales creo que tenemos la obligación de cambiar esto.
Nunca he creido en la magia, desarrollar software es dificil, que algunas herramientas faciliten ciertas actividades del desarrollo (un crud que sale solo, diseño pantallitas arrastrando y soltando componentes) al final a lo único que esta llevando a que a alguien le vendan la moto que con tal framework/herramienta de turno y cuatro "picateclas" puede hacer aplicaciones que salgan como churros, la triste realidad es que luego las aplicaciones están llenas de bugs y no hay quien las mantenga, y no es sólo por falta de test, es por falta de profesionalidad tanto en los propios desarrolladores como en toda la industria a la hora de enfocar el desarollo de software. (salvo excepciones).
En mi opinión nuestra profesión necesita como el comer dar un salto adelante en profesionalidad y calidad, y aqui es donde el testing automatico es una tecnica fundamental (que no la única cuidado, buenos principios de diseño OO, integración continua, gestión de la configuración como dios manda...etc,etc), y ojo que tampoco hablamos de unos niveles de calidad del otro mundo, hablamos simplemente de tener cierto grado de confianza en que lo que le das a tu cliente y por lo que ha pagado unos buenos euros funciona, que seamos realistas, ni a eso llegamos!.
El camino puede ser dificil que no digo que no lo sea, ¿pero que alternativas tenemos?, ¿seguir haciendo porquerias?, yo me niego.
Hola remoh y jcesarperez,
no digo que no haya que probar la aplicación de forma automática , simplemente que no lo veo como un camino de rosas, de todas formas os cuento problemas que veo con los Test.
Lo primero es como hacer un Test de un XML. Me explico:Cada vez más en vez de programar , nos dedicamos a configurar un XML con cosas que hace la aplicación. Y cuando digo XML, tambien puede ser una anotación o lo que sea. ¿Como se prueba eso?. En mi caso en el XML tengo campos requeridos, expresiones regulares, limites de campos, etc. Para cada parametro de configuración hago un Test para ver si el valor está tal y como yo quiero. Pero el coste lo veo excesivo. Además no pruebo realmente nada de código escrito por mi, simplemente estoy porbando si marqué un check indicando que un campo es requerido (tengo un GUI para modificar el XML). ¿Tiene sentido el Test? Yo lo veo un poco absurdo.
Luego otro problema es la relación entre Test. Tengo uno que testea que se puede inserta una fila con datos correctos y luego otros tests (como mínimo tantos como columnas) en los que pongo una única columa incorrecta y el resto de columnas correctas con lo que para que cada Test tenga éxito debe fallar la inserción. Pués bien todos estos Test los veo muy dependientes del primer Test y no se como independizarlos.Igual es que no tengo experiencia haciendo Tests pero veo que es todo un mundo aprender a hacer Test.
Otra cosa que creo que comentaste (Alfredo), es respecto a usar static (o cualquier otra característica del lenguaje) . Tenemos una caracteristicas totalmente razonable de usar como es un static. Y por culpa de los Test no puedo usarlos. Pero si el static es lo más adecuado en mi proyecto, ¿pq tienen que limitarme los Tests? Quizas el problema es que la tecnología de los Test aun está poco evolucionada , igual en unos años google con saca otro lenguaje que facilita la creacion de Test. Pero mientras tanto dejo de enseñar el static en clase porque mejor no usarlo ( esto es una hiperbole).
Otra duda, ¿como hago un Test para probar una expresión regular? Yo suelo probar con un valor correcto y otro incorrecto. Pero, ¿realmente así se prueba la expresión regular?
Respecto a los "picateclas" mi objetivo siempre ha sido que una tecnología permita a los picateclas hacer aplicaciones, ya que de esa forma un profesional con esa misma tecnología podría hacer verdaderas birguerías.
Una posible solución a las dificultades de crear Test, podría ser que se generaran los Test automáticamente a partir del análisis o usar MDD en el que el código se genera automáticamente por lo que no habría que probar el código pq no tendría errores, aunque sería necesario probar el modelo.
Por último me ha venido a la mente el libro de The Art of Software Testing, con el ejemplo del principio del libro de los 3 lados de un triangulo.....y sigo pensando lo jodido que es hacer Tests.
Saludos.
No si un camino de rosas no es, en eso estamos de acuerdo, pero insisto, desarrollar buen software no es tarea facil.
Sobre el tema del XML, en el caso que comentas habrá un framework que se encargue de que todo ese tinglao funcione, el framework desde luego tiene que estar bien testeado. En una apliación que lo use no vas a probar que el framework funcione en detalle y te dedicas más a hacer test de integración. Te pongo un ejemplo, stripes (framework web) tiene anotaciones en xml para validaciones, ¿como pruebas que esas anotaciones están bien puestas?, pues los tios se han montado unos objetos mock que permiten probar el funcionamiento del framework sin necesidad de levantar un app server (aquello del fast). Los frameworks tienen que proporcionar facilidades para testing, y cuando vas a seleccionar un framework para un proyecto es otro parametro importante a tener en cuenta, que tenga buen soporte de testing (ejemplo claro spring vs EJB 2.0, y la evolución de EJB tiene mucho que ver con ser más "amable" con el testing)
Sobre el tema de la dependencia, en los test que involucren bases de datos los suyo es establecer el estado previo de la base de datos antes del test y finalizado el test volver a dejar la bd limpia. En el segundo podcast hablamos de esto, concretamente nosotros usamos Dbunit para esto.
Lo del static no es "no lo uses por los test" es no lo uses porque es en general es una mala practica y los test lo único que hacen es ponerlo de manifiesto. Un test no es más que un usuario de tu clase como otro cualquiera, si el test no puede usar esa clase de forma aislada sin llevarse de regalo sus acoplamientos estaticos tampoco la podras reutilizar en ninguna otra parte. Evidentemente hay casos y casos, no hay que ser radicales, pero los test sólo exijen a tu codigo buenas practicas, bajo acoplamiento y depender de interfaces en este caso. Si hablamos de TDD no hablamos solo de hacer test para comprobar el funcionamiento correcto, TDD es una tecnica de diseño que nos fuerza a respetar una serie de buenas practicas.
El tema de las expresiones regulares, no vamos a demostrar con nuestros test que la implementación de ER del lenguaje funciona, eso vamos a darlo por supuesto, lo que probamos es que esa expresión regular que hemos escrito sirve para el uso que le queremos dar en nuestro contexto, ponemos ejemplos de posibles entradas validas y no validas y listo. La cosa es que si mañana descubrimos un caso en el que la ER no funciona ya tenemos montado todo nuestro entorno para que codificar ese test cueste dos segundos, y cuando lo arreglemos además de demostrar que para ese caso ya funciona nos aseguramos de que sigue funcionando para los anteriores. No tenemos certeza al 100% que para eso tendriamos que demostrar matematicamente los programas, pero si tenemos un nivel de confianza razonable.
Y lo del MDD no lo veo, nunca me ha gustado la idea, ¿dibujar los programas?, al final el diablo esta en los detalles y las reglas de negocio las tienes que expresar en algún sitio si quieres que funcione, a mi un lenguaje escrito me parece muchisimo más expresivo que un lenguaje visual estilo UML, y eso sin hablar de que escribir es infinitamente más productivo que dibujar. Por este camino lo que si veo interesante es el tema de los DSL's. Pero en definitiva esto es jugar a los adivinos, yo quiero que mis aplicaciones estén bien probadas hoy y tenemos los lengaujes y los entornos de desarrollo que tenemos (que hombre tampoco esta tan mal).
Remoh dijo: "el objetivo de este primer podcast era sobre todo poner de manifiesto la enorme importancia de este tipo de tecnicas y animar a la gente a ponerse a la faena"
Pues como veis, el objetivo del podcast está cumplido, ya estamos en la faena. Estoy esperando el segundo podcast (y el tercero si lo hubiera).
Gracias por las referencias de los libros y por el pequeño tutorial.
Enhorabuena por el podcast! Agradezco que se haya hecho en dos partes para que se puedan tratar bien los contenidos ya que es un tema que tengo pendiente y me resulta muy interesante.
Gracias!
Hola de nuevo.
Gracias a vosotros por vuestros comentarios.
@logongas: no entiendo muy bien lo del XML. No capto qué quieres probar exactamente, porque imagino que no es que se construye un xml correcto de acuerdo a un schema predefinido.
Respecto a lo de la bbdd, me pregunto qué quieres probar exactamente. Si es un test unitario del método save de un dao implementado mediante jdbc, yo no haría mucho más de 4-5 casos. Tipo ok con objeto con todos los atributos, ok con objeto con sólo los atributos obligatorios, fallo con objeto null, fallo con objeto duplicado, fallo con objeto con menos atributos de los obligatorios, fallo con objeto con atributo con longitud excesiva. Con esto ya tienes un nivel de seguridad aceptable en tu propio código Java + Sql y además tienes claro (y documentado) el funcionamiento en caso de error. Si luego encuentras algun bug, añades el caso de error en un nuevo test.
Si usas un ORM, la implementación del método dao será basicamente delegar en el orm. No tienes que probar que el código del ORM funciona, para eso ya están los tests del propio ORM. Lo que debes probar son los mapeos y los cascade. Los mapeos de todo tu modelo se pueden probar con 1 único test. Para los cascade Hibernate (otros ORM no sé) tiene un módulo Statistics que te permite consultar qué sentencias se han ejecutado. Pej: si persistes un objeto Persona también querrás asegurar que se ha persistido el objeto Direccion asociado, o sea que han ocurrido 2 inserts.
Ahora bien, si lo que quieres probar es que el usuario no puede realizar ciertas acciones, como guardar una Persona sin introducir el nombre o poner letras en su edad, debes realizar tests funcionales.
Respecto a static y ER, nada que añadir a lo dicho por Alfredo.
En hora buena, felicidades por tan buen podcast... Esperamos con ansia la parte 2.
Sería bueno lanzar un podcast sobre JafaFX (Ventajas, Desventajas, JBI, etc.) Creo que este tipo de podcast que son más técnicos y menos rolleros son tan o más utiles como los podcasts donde se plantea hacia donde va tal o cual estandar o tecnología Java.
Y bienvenida sea la tertulía ;)
Hola jcesarperez,
con lo del XML me refería a que hay partes de la aplicación que en vez de ser código son "ficheros" de configuración como puedan ser un XML. Y que probar la aplicación consistiría en ver si esos XML son correctos, pero como bien dices no me refiero a que sea un XML bien formado , etc. Sino que hemos puesto los valores que hacen que nuestra aplicación haga lo que nos ha pedido el cliente.Y ponía el ejemplo de establecer en un XML que un campo es requerido o que no deber superar el valor de 100 ,etc.
Pero bueno, a ver si en el siguiente Podcast encuentro formas mas fáciles de hacer un Test.
Saludos.
Hola jcesarperez,
casualidades de la vida , acabo de encontrar en dzone un post sobre una herramienta llamada XMLUnit. Quizas era lo que yo estaba buscando para probar los XML.
XMLUnit - JUnit and NUnit testing for XML
Pero menos mal que JUnit era muy sencillo, pq tenemos: JUnit, Selenium, DBUnit, XMLUnit,..... y no se si habrá mas cosas.
Buenas,
Solo comentar que en la segunda parte se hablan precisamente de librerías, frameworks concretos (a parte de algunas cosas más). Precisamente, se comentan todos estos que indica logongas. :) (Que casualidad!).
Saludos, Jorge
Escribe tu comentario