Ok… Aquí estamos yo y Clojure. Haciendo amigos.

Documentándome

Ya leí ”Seven languages in seven weeks”, que me enseñó mis primeros pasos en Clojure. El lenguaje, fascinante, aunque esa falta de sintaxis constituya una barrera de entrada importante para mi. Confieso: Lo leí sin hacer los ejercicios y, la verdad, con Clojure, sin trabajar y sudar no hay entrada posible. Quedó en mi mente como una anécdota de lo que se puede hacer por ahí con él.
Después empecé con ”Programming Clojure”, de Stuart Halloway. El libro es muy bueno, creo. Pero adolece de un gran defecto, para mi gusto. No usa TDD. De hecho, las pruebas unitarias las explica en el último capítulo, como si no fuesen necesarias hasta que empiezas a desarrollar “in the wild”. ¿Y como pruebo entonces los ejemplos? En el REPL, el entorno interactivo que va ejecutando cada sentencia según la escribo.

TDD

Ok, probaremos. Esta vez, programando por el camino. Probando cada ejemplo. Lento pero seguro. Pero me incomoda no estar escribiendo tests de lo que aprendo, que me servirían a modo de tutorial. Quiero aprender el lenguaje con un enfoque TDD, aprendiendo cada ejemplo con una prueba unitaria que me lo explique. Así enseño Javascript y así quiero aprender Clojure.
De ”Programming Clojure” aprendo que (test v) evalua el metadato :test de v asumiendo que lanzará una excepción si falla, mientras que (assert v) evalua v y lanza una excepción si no es un valor cierto. Pero este enfoque no permite separar las pruebas del código que prueban. También aprendo que existe un framework de Stuart Sierra llamado clojure.test (antes clojure.contrib.test-is) para escribir pruebas separadas del código.
Y cuando ya me dispongo a aprender clojure.test descubro que el propio Stuart Sierra hace una crítica del mismo en la que dice que va a empezar un nuevo framework desde 0 para el mismo propósito: lazytest.
Parece que lazytest es lo que busco y que, como en tantas otras ocasiones, no es mayoritario. Me interesa, sobretodo, porque se convirtió, para su autor, en el intento de crear el framework perfecto para BDD/TDD:

Lazytest started with the simple desire to fix all the problems I found with clojure.test, but it evolved into an attempt to make the perfect behavior-driven development framework for Clojure, incorporating all the best ideas from TDD/BDD frameworks in other languages.

¿IDE?

¿Y cómo empiezo a usar lazytest? Quiero escribir código Clojure que quede en un repositorio y que contenga pruebas automatizadas para todo. Y quiero que se ejecuten tan a menudo como sea posible.
Esto es, ya no voy a usar REPL. Tengo que editar ficheros. Byword, el programa para Mac que uso para escribir este post en Markdown es una maravilla… pero no para escribir código. Si me fijo en qué usan los del mundillo… Stuart Sierra usa Emacs. Pero no me veo usando Emacs, lo siento.
Después de buscar un poco, me encuentro este interesante artículo: Clojure IDEs - The Grand Tour. Olvidando vi y Emacs por que no son mi estilo (ya no, por lo menos, y aún no), y olvidando La Clojure porque no tengo IntelliJ (por más que me mole) me queda Counter Clockwise para Eclipse y Enclojure para Netbeans.
Tendré que echarles un vistazo a ambos. Aunque las notas acerca de los fallos de Enclojure me echan un poco para atrás.

TDD en la IDE

Por cierto, desde que probamos Infinitest, no puedo vivir sin que mis tests se ejecuten en el mismo momento que grabo un fichero con modificaciones. Tanto lazytest como clojure.test permiten no solo ejecutar las pruebas a mano mediante un script (o como un paso mas de la Maven build) si no que tienen otro script que observa los ficheros de código fuente y ejecuta las pruebas en cuanto cambian. Claro que, hasta donde se, reportan los errores en la consola que lo esté ejecutando. Yo quiero lo equivalente a Infinitest, pruebas unitarias ejecutadas al grabar el fichero pero con el reporting integrado en Eclipse.

Código fuente y gestión de dependencias

¿Y cómo organizo el código fuente de mi(s) proyecto(s)? Desde el mundo Java la elección obvia es Maven y Stuart Sierra, de nuevo, me da un proyecto de ejemplo. Aunque parece que la opción más apropiada para desarrolladores Clojure, es Leiningen, un Maven on steroids para clojureros.

Conclusiones

Así que, antes de avanzar mas, mis siguientes pasos serán:

• Elegir una IDE para Clojure. Seguramente empezaré por echarle un vistazo a Counter Clockwise.
• Elegir una estructura de proyecto y una herramienta de gestión de dependencias. A priori apostaría por Leiningen, pero no lo conozco.
• Elegir un framework de unit testing que me permita hacer TDD. Seguramente sería lazytest.
• Comprobar (optimista yo) que es posible desarrollar mediante la IDE elegida con la estructura de proyecto y framework de pruebas también elegidos. Si uso Leiningen y lazytest no habrá incompatibilidades entre ellos, puesto que he descubierto el primero en la documentación del segundo. Pero lo de usar Eclipse Counter Clockwise con esos no está tan claro… A las malas, Maven con Eclipse se integran razonablemente mal (malo conocido), y Maven tampoco tendría problemas con lazytest.