El lado oscuro de las pruebas.

Saludos.

De un tiempo a esta parte, con la aparición de metodologías extremas, diseño guiado a pruebas y herramientas tipo jUnit, se han puesto de moda las pruebas. Parece que, cuantas más pruebas tenga un programa, mejor. Pero tener un número elevado de pruebas tiene un lado oscuro que puede traer problemas.

Si las pruebas son pequeñas y simples, las podemos escribir en un momento, pero si aumenta su tamaño (y no podemos dividirlas en pruebas más pequeñas) se hacen difíciles de escribir. Además a más código más errores, por lo que tenemos que perder tiempo depurándolas. Si nuestra prueba tiene mucho código o es compleja, ¿cómo podemos asegurarnos de que nuestra prueba funciona adecuadamente? ¿Tenemos que escribir una prueba para probar la prueba?.

Esto es malo, pero podemos encontrar algo todavía peor. Supongamos que tenemos una clase y 10 pruebas que dependen de dicha clase. Con el uso se ha descubierto que hay una manera mejor de crear objetos de esa clase cambiando los constructores. Ese cambio supondría, no solo cambiar en el código donde se crean objetos de esa clase (muy pocos si programamos bien 8) ) sino tener que modificar esas 10 pruebas.
Además habría que repasarlas para comprobar que sigan teniendo sentido después de la modificación y, probablemente, escribir pruebas nuevas.

En este caso el problema no es muy grande, pero si cambiamos (o refactorizamos) mucho código, el número de casos de casos de prueba a modificar aumenta, con el consiguiente gasto de tiempo para modificarlas. Recordemos que las pruebas no son parte del sistema (no se la entregamos al cliente ni, probablemente, el cliente aprecie su utilidad), por lo que no debemos gastar demasiado tiempo con ellas.

Esto nos puede llevar a dos decisiones igual de malas: o bien no modificar el código para seguir aprovechando las pruebas que ya tenemos, o, lo más común, modificar el código y tener un conjunto de pruebas obsoletas e inservibles.

Este problema no es exclusivo en las pruebas de código "tipo jUnit". También sucede lo mismo trabajando, por ejemplo, con robots de prueba que capturan pulsaciones de teclado o ratón y luego las reproducen. En este caso, un mínimo cambio en la interfaz gráfica puede obligar a modificar (o a volver a grabar) un buen número de pruebas.

En resumen. Cuanto más pruebas, por ejemplo pruebas de código, tengamos, más atados estamos a dicho código y menos ganas de cambiar nada tenemos..

¿Cuál puede ser una la solución?. Creo que una buena alternativa sería generar las pruebas de manera automática. Si tuviéramos un programa que permitiera apretar un botón y obtener un buen conjunto de pruebas (e incluso ejecutarlas), no nos preocuparíamos a lo hora de cambiar el código. En cada cambio descartaríamos todas las pruebas obsoletas y generaríamos pruebas nuevas fácilmente.

Esto es muy fácil de decir pero muy difícil de poner en práctica (por no decir imposible). Espero seguir hablando de esto en futuras entradas.

Texto con formato e imágenes en aplicaciones web

Saludos.

Recientemente he estado haciendo una miniconsultoría (en plan "Amigetes Conculting") que me ha llevado a buscar editores web, o editores de texto lo más completos posibles para integrarlos en una aplicación PHP. A continuación comento lo que he encontrado.

En el siguiente enlace se puede encontrar una lista muy completa con opciones para todo tipo de plataformas y lenguajes: http://www.htmlarea.com/

De todos los que he visto, el que más me ha gustado para PHP (también disponible para ASP.NET) es Spaw, que se distribuye bajo licencia GPL para usos no comerciales (www.solmetra.com/spaw/ y sourceforge.net/projects/spaw/).

Sin embargo, aunque es un componente bastante evolucionado y cuenta con un foro bastante dinámico (en SourceForge), yo no he consegido hacerlo funcionar. Una lástima.

Por ese motivo he optado por htmlArea (http://www.dynarch.com/projects/htmlarea/) que, si bien no es tan vistoso ni icluye tantas opciones, cumple sobradamente. Además está íntegramente en JavaScript, por lo que se adapta a casi cualquier plataforma.

También existen plug-in que lo extienden, por ejemplo a la hora de incluir imágenes
(http://www.zhuo.org/htmlarea/). Su licencia es BSD.

HtmlArea lo utilizan aplicaciones tan importante como la plataforma de e-Learning Moodle.

Ya no hay excusas para crear formularios que no admitan texto con formato.