Observaciones sobre Pruebas Unitarias

Analizando las constantes e incansables ocasiones que nuestro líder de proyecto habla sobre la necesidad de hacer pruebas unitarias (automatizadas), y que no siempre estuve de acuerdo, dado el tiempo que se requiere para construirlas y que en la mayoría de las veces, las fechas de entrega negociadas con el cliente nos ahorcan en los tiempos que podemos dedicar a esta práctica, me he dado cuenta de lo siguiente.

Evidentemente sería mucho más útil tener pruebas unitarias que se construyan desde un principio para que en la vida del proyecto se ejecuten periódicamente y nos aseguremos que las partes de dicho proyecto siguen funcionando como deben, independientemente de la integración de nuevos módulos, refactoring de clases, optimización de código e inclusive corrección de estilo.

Pero para lograrlo y evitar el tedio al realizar las pruebas unitarias considero que hay que pensar en lo siguiente:

1. Para no hacer esfuerzos sin ganancia, es absolutamente necesario planear los puntos críticos a probar unitariamente en los distintos módulos del proyecto.
   
2. Así como los Casos de Uso se desarrollan antes que el diseño y los diagramas UML preceden a la construcción de un proyecto, es vital que las pruebas unitarias se armen antes de la construcción.
   
3. No es necesario crear una prueba unitaria por cada Dao, Servicio, Pojo, Controller, ViewHelper o Utilería habido o por haber.
   
4. Las pruebas que deberían automatizarse son aquellas que tienen una mayor probabilidad de no cambiar (en concepto) a lo largo del proyecto. Cuando sea necesario integrar ajustes nuevos y provoquen un fallo en las pruebas automatizadas ya existentes, se pueden actualizar dichas pruebas con cambios mínimos para mantenerlas como símbolo de que nuestro sigue funcionando con los requerimientos de un principio.
5. Es necesaria una comunicación plena en el equipo de desarrollo por cuestiones de conflictos de actualizaciones, sobre todo si se esta trabajando en el mismo repositorio y los cambios de uno afectan a las pruebas unitarias de otro.
6. Para visualizar el correcto funcionamiento de una prueba unitaria y localizar el error si esta falla (sin hacer debug) es realizar un correcto logging, de manera que éste mismo explique claramente la etapa que transcurre (con datos self-explaining) y compruebe el estado del proceso en ejecución.
7. Es importante contar con un grupo de herramientas adecuadas que nos permitan conectarnos a base de datos y trabajar con datos, simular comportamientos de servicios no-tan-fácilmente-probables, acceder a archivos y verificar su contenido y un grupo de agregados para comprobar los resultados de cada prueba. Quizá funcionen como adaptadores, servicios, factories o daos dedicados exclusivamente para comprobar cosas. Junit tiene un addons que se ve bastante bien.
8. El que las pruebas unitarias estén correctamente automatizadas y con un adecuado logging (incluyendo los elementos a probar) implica que ya no es necesario hacer debugging para encontrar los errores (algo que solo se puede hacer manualmente).
   

Una vez planeado así, podríamos ver los resultados que dice el articulo de jamesgolick en su apartado "Breaking Even" : 'si te cuesta 20min. construir una prueba automatizada y 1min. una prueba manual, llegar al punto critico para compararlas es que probases manualmente 20 veces; después de eso, la prueba automatizada se vuelve mucho mas barata y la manual obviamente mas cara, disparándose ambas en sentido contrarios'.

Ustedes que piensan? alguna otra recomendación?

Buenas prácticas con Spring

1. No abusar de las inyecciones
2. Utilizar inyecciones por dependencias (setter) en vez de por constructor
3. Agregar una descripcion al archivo de configuracion xml y notificar al equipo sobre los cambios realizados
4. Usar ids como identificadores de beans
5. Integrar archivos de configuración mediante ApplicationContext y no usar imports de xml
6. Reutilizar definiciones de beans
7. Si se usa inyección por constructor, utilizar TYPE en vez de INDEX para los argumentos del constructor
8. Usar convenciones de nomenclatura para nombrar los beans
9. Evitar el uso de autowiring

Leer más en dosIdeas

Instalar un artefacto en el repositorio de maven

Para instalar un artefacto en un repositorio local de maven. Por lo general lo copia en el directorio home_del_usuario/.m2/repository/, salvo los ajustes que hagamos en archivo de configuración de maven: settings.xml.

mvn clean install

Para instalar un artefacto de terceros hacer:

mvn install:install-file -Dfile=foo.jar -DgroupId=org.empresa -DartifactId=foo -Dversion=1.2.3 -Dpackaging=jar

Para instalar un artefacto en un repositorio remoto de maven.

mvn deploy:deploy-file -Dfile=foo.jar -DgroupId=org.empresa -DartifactId=foo -Dversion=1.2.3 -Dpackaging=jar -DrepositoryId=focus-repository -Durl=scp://host/home/mvn/public_html/repository

Intro comandos Maven 2.0

Para obtener ayuda del comando de Maven 2:
mvn --help

Sintaxis general:
mvn plugin:target [-Doption1 -Doption2 ...]

Para crear un proyecto JAR:
mvn archetype:create -DgroupId=com.empresa.proyecto -DartifactId=nombreAplicacionJAR
* Si vas a crear un módulo dentro de otro proyecto maven previamente creado, debes ejecutar el mismo comando pero dentro o al nivel raiz del proyecto que va a contener dicho módulo, automáticmante maven, hace que el nuevo proyecto sea módulo del proyecto a nivel raíz en el que te encuentras parado. Observa el tag en el pom.xml del proyecto padre y el tag del proyecto hijo después de ejecutar el comando.
Para crear un proyecto WAR: