Unit Testing es a Literate Programming lo que Functional Testing es a...

[Jose San Leandro <jose.sanleandro@xxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aproximadamente hace ya un par de años desde que se comenzara a adoptar las
metodologías ágiles y las prácticas de programación extrema como guías para
conseguir paliar la debacle en cuanto a credibilidad, costes y calidad en
general de los proyectos software, acentuada en la época dot-com. Coincidió
con la expansión de la aplicación de patrones de diseño y de la
disponibilidad de bibliografía al respecto.
La corriente XP [1] ha conseguido multitud de adeptos, que comparten las
"doctrinas" y el fervor por los nombres propios (dígase Beck, Martin, Fowler,
etc.).
Más allá de consideraciones intangibles, como que lo importante en un proyecto
no son los métodos sino las personas [2], las consecuencias beneficiosas de
la utilización de frameworks xUnit queda, en mi opinión (dejando a un lado
consideraciones "humanas" como la reticencia al cambio o la disciplina que
requiere), fuera de toda duda.
Algo similar, pero quizá menos adoptado en la práctica, sucede con Literate
Programming [3]. La documentación tiende a ocupar un papel secundario, no
prioritario, y relegado a la etapa final del proyecto. La documentación
técnica se mantiene en sincronía con el código durante un breve espacio de
tiempo. Literate Programming, al contrario que el uso de frameworks xUnit,
requiere herramientas IDE específicas, ya que su uso no es no-intrusivo: el
formato del código fuente no es compatible. Algunas variantes a LP, como
Elucidative Programming [4] dedican un esfuerzo al desarrollo de herramientas
que favorezcan su uso.

Pongamos un ejemplo de un proyecto en el que se ha usado XP de un modo en mi
opinión más razonable que las doctrinas de los impulsores de la metodología.
Digamos que el proyecto ha utilizado TDD [5], simultáneamente con LP.
Una persona nueva que se incorpore al proyecto dispondrá no sólo de la
documentación inherente a las pruebas unitarias (a-la XP), sino además de una
descripción estructurada de cada una de las clases que lo forman. Como
resultado, dispondrá de extensa documentación, pero cuya granularidad es cada
fichero de código fuente (en Java, cada clase o interfaz). Es decir,
dispondrá de información similar al Javadoc del fichero, con ejemplos
proporcionados por las pruebas unitarias, y con la descripción de la
semántica de la clase y la posible relación de sus métodos entre sí.

Sin embargo, a la hora de resolver errores en funcionalidades existentes a
nivel de aplicación o de implementar nuevos requisitos funcionales, esa
documentación es insuficiente. Típicamente, en los errores se parte del
contexto en el que se dió (en Java el stack trace), para recorrer en sentido
inverso el código y detectar el problema (*). No suele haber documentación que 
describa en detalle el camino concreto que sigue el flujo de ejecución en 
cada funcionalidad de alto nivel. En terminología AspectJ [6], dicho flujo 
sería el subconjunto del codigo que satisface el pointcut cflow(..).

En este supuesto, posiblemente lo que permitiría una mayor suavidad en la
curva de aprendizaje del código sería una herramienta LP que siguiera el
flujo que se ejecuta al dar el servicio requerido por cada caso de uso de la
aplicación. En mi opinión, sería interesante disponer de una herramienta tal
que, una vez indicado el punto de entrada a la aplicación para un caso de uso
concreto, por ejemplo mediante tags Javadoc, recorriese el flujo de ejecución
a partir de ese punto, indicando a su vez en los métodos afectados el hecho
de que "el método es usado por el caso de uso x", y finalmente generara la
estructura de un documento (como pueden ser <section> de DocBook [7]), de
forma que siempre estuviera sincronizado dicho flujo con la estructura de tal
documento.
Por supuesto, eso no implicaría necesariamente la existencia de contenido en
dicho documento, ni la validez del mismo, pero sí quedaría de manifiesto su
ausencia.
De esta forma, el contexto en el que aparecen los posibles errores se podría
averiguar en sentido inverso, de atrás hacia adelante: "esta funcionalidad
sólo llama a este método para tal propósito", con lo cual el código ofrecería
una mayor transparencia.
Otras consecuencias de una herramienta como la descrita, en un grado de
sofisticación mayor, podrían ser la disponibilidad de posibilidades tales
como:
- -Generar métricas tales como "el 15% del código no se utiliza".
- -Omitir y/o añadir casos de uso y su lógica asociada en tiempo de compilación,
- -Analizar la transaccionalidad no a nivel de método sino a nivel de paso
intermedio en la funcionalidad,
- -Ofrecer un contexto más rico a la hora de presentar información sobre cada
error, al poder referenciar a la parte específica de la documentación.

Referencias:
[1] http://www.extremeprogramming.org/
[2] http://www.agilemanifesto.org/
[3] http://www.literateprogramming.com/
[4] http://www.cs.auc.dk/~normark/elucidative-programming/
[5] Test-Driven Design (Development) http://citeseer.nj.nec.com/527827.html,
http://www.artima.com/intv/testdriven.html
[6] http://eclipse.org/aspectj/
[7] http://www.docbook.org/

(*) En Java, curiosamente, se suele prescindir de deshabilitar la compilación
con símbolos de depuración y sin optimizaciones, bajo la argumentación de que
en caso contrario en más difícil averiguar dónde y por qué se da cada error.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFARaOqCAvt6RF8M0cRAm8FAKC1ZeKvHdND+9D4Nw8vsow9hO8QKACcDYjW
zN9TJbYs3eo946S9iUzA2Ow=
=uMTJ
-----END PGP SIGNATURE-----