Testing Experience

Esta tarde, al llegar a casa después del trabajo me he encontrado con una grata sorpresa. Tenía en el buzón el cuarto número de la edición impresa de la revista Testing Experience. Creo recordar haber comentado su existencia por estos lares en alguna ocasión, y ahora vuelvo a recomendaros una publicación más que interesante dentro del mundo del desarrollo del software y, en particular, de la parcela correspondiente a las pruebas del mismo.

Las revistas están disponibles para su descarga en la web de la revista,aunque es posible suscribirse de forma gratuita para recibirlas impresas. Aunque siempre abogo por el uso del ordenador para la lectura de artículos técnicos y la consulta de libros de informática, hay ocasiones (como cuando el equipo de trabajo las consulta de forma intensiva, o pueden compartirse con colegas, compañeros y amigos) en las que creo que es incluso más interesante (y ecológico, pese a lo que pueda parecer) contar con un ejemplar impreso.

Además, y aunque resulte un poco off-topic, este mediodía cuando me dirigía a casa a almorzar (sí, envidiosillos, es la ventaja de vivir cerca del trabajo, jejeje) he visto dos cuervos sobrevolando la entrada del Parque Tecnológico. Aunque es habitual contemplar aves de paso, por estar ubicado cerca de la desembocadura del Guadalhorce, no es tan común que nos topemos con este córvido, aunque no es la primera vez que les veo por aquí. En cualquier caso, hoy su paso guarda un especial significado, ya que se celebra el bicentenario del nacimiento de Edgar Allan Poe, del que seguro que conocéis su poema El Cuervo.

Pues nada, lo dicho. Os dejo para sumergirme en la lectura de la revista. Y es que hay problemas causados por los bugs y problemas de diseño que no se han detectado por no llevar a cabo unas buenas prácticas de testing que dan más miedo que los cuentos del inmortal autor norteamericano ;) .

El ascenso de Ícaro

El desarrollo guiado por pruebas o TDD nos permite codificar nuestras aplicaciones de una forma más segura, ya que ante cambios en el código existente o inclusión de nuevas funcionalidades, basta pasar nuevamente todas las pruebas (incluyendo, en su caso, las nuevas que sean pertinentes) para asegurarnos que las modificaciones no han alterado su funcionamiento anterior. Una de las herramientas que nos permiten llevar a cabo este desarrollo son los frameworks de prueba, de los que existen de todos los sabores y gustos conocidos para cada lenguaje de programación o plataforma de desarrollo. En el caso del .NET Framework podemos citar, entre otros, el extendidísimo NUnit en sus líneas de desarrollo 2.x y 3.x, MbUnit muy orientado a la extensibilidad del mismo, MSTest que viene “de serie” con Visual Studio (excepto las ediciones Express) y xUnit.net, que nació tras las lecciones aprendidas de otros frameworks de pruebas unitarias y que poco a poco va adquiriendo mayor peso entre la comunidad de desarrolladores.

Estos frameworks suelen consistir en un core de pruebas que nos permite, gracias al etiquetado mediante atributos de nuestras clases y métodos, la ejecución automatizada de los tests. También incorporan clases de extensión y demás funcionalidades, y suelen permitir la ejecución de las pruebas desde la propia consola del sistema, o a través de una interfaz gráfica que nos hace la vida más fácil a los usuarios de los mismos. Pues bien, días atrás estuve evaluando xUnit.Net como alternativa a NUnit de cara a nuevos desarrollos, y su inclusión dentro del proceso de integración continua que facilitan herramientas TeamCity, de la que me gustaría hablar algún día. El caso es que, probando xUnit.net, el GUI que ofrece “de serie” el framework es ciertamente triste, aunque sea una versión temprana del mismo. Así las cosas, me planteé probar su funcionamiento con alguna otra aplicación que permitiese llevar a cabo campañas de prueba de una forma más sencilla y con un mayor control sobre los resultados arrojados por los tests. Aunque la oferta a este respecto, por lo que pude ver, no es demasiado extensa (buscaba un GUI suficientemente flexible como para permitir la ejecución de pruebas con xUnit.net sin demasiado trabajo de configuración previa, o sin tener que desarrollar scripts en NAnt, MSBuild o similares), encontré mi opción ideal en Gallio, una plataforma de automatización, abierta y extensible, que puede integrarse con numerosos frameworks de pruebas en .NET. De hecho, es tan flexible que permite la ejecución de series de test desarrollados sobre diversos frameworks sin mayor problema. Incorpora un GUI, Icarus, cuya instalación y uso es tan simple como el propio GUI de NUnit, permitiendo además obtener informes muy vistosos como puede observarse en las diversas capturas que acompañan a la entrada de hoy.

El Explorador de Tests nos permite seleccionar aquellas pruebas que deseamos ejecutar.

Una ejecución de tests con un resultado ideal.

El Explorador de Tests correspondiente a la ejecución anterior.

El log de ejecución con algunos tests fallidos.

No voy a entrar demasiado en profundidad en la aplicación, ya que su uso es muy intuitivo y simple, y lo único de lo que quería dejar constancia es del interés que ha suscitado en mí precisamente por eso, porque permite incluso desarrollar nuevas pruebas sobre el código existente en un framework de pruebas distinto al ya existente, y pasar las pruebas en su totalidad desde una misma aplicación. En contra suya únicamente he notado una ligera lentitud en la carga y ejecución de los ensamblados que contienen las pruebas a pasar.

Un completo informe en HTML.

¿Y en vuestro equipo, desarrolláis basándoos en TDD? ¿Qué framework de pruebas usáis? ¿Cuál os gusta más y por qué?

Usando Java desde .NET

En los fines de semana aprovecho –como todos, imagino- para ponerme al día con todo aquello que, por un motivo u otro, no he podido hacer durante el resto de la semana. Esto incluye todo tipo de lecturas (entre las que se incluye la que os comento al final de la entrada) y pruebas que quiero realizar de nuevo software: aplicaciones, sistemas operativos… o como es el caso de hoy, unas librerías y una máquina virtual. En concreto, hablo de IKVM.NET, una implementación libre de Java para Mono/.NET Framework. Posiblemente recordaréis la batalla legal que establecieron Sun y Microsoft hace unos años (una de tantas) sobre el particular uso que de Java hacía la compañía de Redmond, modificando a su antojo las particularidades del lenguaje. También hubo conflictos en si Windows XP bloqueaba o no el uso de Java, y a resultas de todo aquello, Microsoft dejó de poder usar Java (al menos, distribuir un Java “modificado”), y esto supuso el lanzamiento de la plataforma .NET (“su” Java modificado ;) que, de paso, incluye entre sus lenguajes J#, que es compatible a nivel de sintaxis con Java). La cuestión es que, como siempre, los desarrolladores y usuarios de los sistemas somos los perjudicados ante estas diferencias, ya que nos encontramos con decenas de entornos similares ante los que decantarnos, habitualmente según lo haga también el mercado. En la variedad está el gusto, dicen, y no afirmaré lo contrario, pero en ocasiones resulta engorroso encontrar soluciones parciales a nuestros problemas, porque parte de lo que necesitamos está en un lenguaje, otra parte en otra, y debemos habilitar todo tipo de mecanismo de interoperabilidad entre esos sistemas heterogéneos para conseguir alcanzar nuestro objetivo.

Pero bueno, comencé diciendo que iba a hablar de IKVM.NET y, como siempre, comienzo a divagar. La herramienta de que os hablo consta de una máquina virtual Java implementada completamente en .NET, así como una implementación de las librerías Java en .NET y diversas herramientas que permiten la interoperabilidad Java-.NET. La instalación es muy simple, basta con descargar el instalador y ejecutarlo. Una vez hecho esto, nos será posible escribir aplicaciones en Java usando ensamblados .NET y que serán compiladas como CIL, o reutilizar código en Java desde .NET. También es posible convertir archivos .jar a ejecutables .NET usando una herramienta que incorpora el paquete de IKVM.NET. Posiblemente tenga oportunidad de hacer un uso mayor del mismo en alguna aplicación real dentro de poco, por lo que ya os iré comentando mi parecer si me encuentro con algo "extraño". De momento, un hola mundo en Java funciona desde .NET :) .

Aún me queda por probar Moonlight, el port de Silverlight a Mono. Aunque voy a ver si convenzo a mi amigo Fernando, de Albloguera, para que rompa su prolongado silencio con alguna entrada sobre este asunto ;) .

¡Ah, y no se me olvida! La lectura que os comentaba la encontré ayer revisando posts que había dejado de lado durante la semana. En Pensamientos Ágiles comentaban un artículo de InfoQ sobre el uso de piezas de Lego (cuyas figuritas, por cierto, cumplían 30 años hace unos días) para la gestión ágil de proyectos. Esto, que podría parecer un absurdo o una extravagancia (ahora lo llaman frikismo :) ), tiene realmente su interés. Por lo que he podido leer al menos, el uso de estas piezas para definir tareas y “encajarlas” según las dependencias entre éstas y su prioridad da una visión rápida de lo que tenemos pendiente. Al menos, resulta mucho más claro a golpe de vista que una pizarra llena de postits. En cualquier caso, se trata de una interesante aproximación al tema del desarrollo ágil del software, tan en boga (y con razón) en nuestros días.