viernes, 30 de octubre de 2009

Pruebas de base de datos con DbUnit

Cuando se desarrollan aplicaciones que acceden a una base de datos, es conveniente verificar que los datos se están manipulando de forma correcta. Para ello, es necesario hacer pruebas sobre el código que realiza esta manipulaciones de datos.

JUnit es un framework que nos ayuda a la hora de hacer pruebas en nuestra aplicación. Además, también podemos usar DbUnit, que es una extensión de JUnit que permite llevar la base de datos a un estado definido antes de cada prueba y que proporciona clases que nos ayudan a realizar pruebas sobre el contenido de una base de datos.

DbUnit permite importar y exportar el contenido de la base de datos a ficheros xml. Por ejemplo, la tabla PROFESORES se define de la siguiente forma:

Un registro en la tabla PROFESORES, se expresaría en xml como:
<profesores PROFESOR_ID="3" NOMBRE="nombre_profesor"/>

Se puede apreciar que el nombre del elemento es el nombre de la tabla y los distintos atributos son los campos de la tabla y su valor para este registro.

Mediante registros de este tipo se pueden generar distintos conjuntos de datos (datasets) en ficheros xml, que pueden servir como semillas para probar el código que accede a la base de datos en situaciones adecuadas para cada prueba.

Vamos a ver como exportar un esquema completo de la base de datos utilizando DbUnit. En primer lugar, se debe obtener una conexión a la base de datos. Se puede hacer de la siguiente forma:
Class.forName("com.mysql.jdbc.Driver");
Connection jdbcConnection =
DriverManager.getConnection(
"jdbc:mysql://localhost/bdprueba",
"user",
"pwd");
IDatabaseConnection connection =
new DatabaseConnection(jdbcConnection);

Posteriormente pasamos a exportar los datos que hay actualmente en la base de datos. Al exportar hay que tener en cuenta el orden de las tablas ya que se podría romper la integridad referencial que existe entre ellas. Para ello se crea un dataset al que se añaden las tablas de forma ordenada, que se pueden obtener a partir de un DatabaseSequenceFilter:
DatabaseSequenceFilter filter = 
new DatabaseSequenceFilter(connection);
IDataSet datasetAll =
new FilteredDataSet(
filter,
connection.createDataSet());
QueryDataSet partialDataSet =
new QueryDataSet(connection);

String[] listTableNames =
filter.getTableNames(datasetAll);
for (int i = 0; i < listTableNames.length; i++) {
final String tableName = listTableNames[i];
partialDataSet.addTable(tableName);
}

Ahora se exportaría este dataset a un archivo xml:
FlatXmlDataSet.write(partialDataSet,
new FileOutputStream("dataset.xml"));

<?xml version='1.0' encoding='UTF-8'?<
<dataset>
<academias/>
<estilos ESTILO_ID="1" NOMBRE="nombre_estilo"
DESCRIPCION="descripcion_estilo"/>
<estilos ESTILO_ID="3" NOMBRE="nombre_estilo"
DESCRIPCION="descripcion_estilo"/>
<estilos ESTILO_ID="4" NOMBRE="nombre_estilo"
DESCRIPCION="descripcion_estilo"/>
<estilos ESTILO_ID="6" NOMBRE="nombre_estilo"
DESCRIPCION="descripcion_estilo"/>
<estilos ESTILO_ID="8" NOMBRE="nombre_estilo"
DESCRIPCION="descripcion_estilo"/>
<estilos ESTILO_ID="9" NOMBRE="nombre_estilo"
DESCRIPCION="descripcion_estilo"/>
<estilos ESTILO_ID="10" NOMBRE="nombre_estilo"
DESCRIPCION="descripcion_estilo"/>
<estilos ESTILO_ID="12" NOMBRE="nombre_estilo"
DESCRIPCION="descripcion_estilo"/>
<clases/>
<academia_clase/>
<profesores PROFESOR_ID="3" NOMBRE="nombre_profesor"/>
<profesores PROFESOR_ID="6" NOMBRE="nombre_profesor"/>
<profesores PROFESOR_ID="9" NOMBRE="nombre_profesor"/>
<profesores PROFESOR_ID="12" NOMBRE="nombre_profesor"/>
<clase_profesor/>
<profesor_estilo PROFESOR_ID="3" ESTILO_ID="3"/>
<profesor_estilo PROFESOR_ID="6" ESTILO_ID="6"/>
<profesor_estilo PROFESOR_ID="9" ESTILO_ID="9"/>
<profesor_estilo PROFESOR_ID="12" ESTILO_ID="12"/>
</dataset>

Tras esto se ha obtenido un dataset que puede ser usado como semilla para una prueba.

A la hora de hacer pruebas, DbUnit proporciona la clase DatabaseTestCase, que sirve como clase base para las pruebas. Esta clase tiene algunos métodos que debemos sobreescribir. El método getConnection() proporciona la conexión a la base de datos, de forma similar a como hemos visto antes:
protected IDatabaseConnection getConnection() 
throws Exception {

Class driverClass =
Class.forName("org.gjt.mm.mysql.Driver");

Connection jdbcConnection =
DriverManager.getConnection(
"jdbc:mysql://localhost/bdprueba",
"user",
"pwd");

return new DatabaseConnection(jdbcConnection);
}

El método getDataSet() proporciona un dataset que sería la semilla para la prueba que vamos a ejecutar:

protected IDataSet getDataSet() throws Exception {
return new FlatXmlDataSet(
new FileInputStream("dataset.xml "));
}

Los métodos getSetUpOperation() y getTearDownOperation() indican lo que debe hacer cada método antes y después de cada prueba. Antes de cada prueba vamos a limpiar la base de datos y a volver a dejarla en el estado que proporciona el dataset que hemos exportado anteriormente, y después de cada prueba no haremos nada:
protected DatabaseOperation getSetUpOperation() 
throws Exception {
return DatabaseOperation.CLEAN_INSERT;
}

protected DatabaseOperation getTearDownOperation()
throws Exception {
return DatabaseOperation.NONE;
}

Tras esto, podemos escribir nuestros casos de prueba en la clase que extiende de DatabaseTestCase, sabiendo que las pruebas partirán de un estado definido.

Referencias:
http://dbunit.sourceforge.net/index.html
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=DBUnitEI
http://onjava.com/pub/a/onjava/2004/01/21/dbunit.html
http://www.oreillynet.com/onjava/blog/2005/10/dbunit_made_easy.html

lunes, 26 de octubre de 2009

Agile Open Spain

Los días 23 y 24 de Octubre se ha celebrado en la Escuela Universitaria de Informática del Campus Sur de la Universidad Politécnica de Madrid el Agile Open Spain, organizado por Agile Spain.

El Agile Open Spain tenía como objetivo la difusión de la metodologías ágiles en España, compartiendo experiencias entre todos los participantes. Se ha desarrollado basándose en el formato Open Space.

La tarde del viernes 23, tras la introducción al evento por parte de la organización, cualquier participante pudo presentar los temas que más interés tenían para él. Tras votación por parte de los asistentes, se seleccionaron los más votados para confeccionar el horario de charlas para el día siguiente, en el que se establecieron 5 turnos de charlas con 6 charlas distintas en cada uno para escoger.

Voy a comentar las charlas en las que yo estuve, que, desgraciadamente, no fueron todas las que me habría gustado estar.

Integración continua

La integración contínua fue el tema de la primera charla a la que asistí. Fue conducida por Juan Gutiérrez y en ella se habló de lo que es la integración continua, presentándola como un proceso continuo de integración del trabajo que se lleva a cabo dentro de un proyecto, que aglutina una serie de buenas prácticas y que está apoyado por una serie de herramientas que permiten automatizarlo.

Algunos asistentes hablaron de sus experiencias con la integración continua en sus proyectos y se llego a exponer el sistema de integración contínua con que uno de los asistentes trabajaba.

Se recalcó la idea de que el principio de la integración es el control de versiones (CVS, Subversion, Git, …) y las herramientas de construcción automática (Ant, Maven…) y que, a partir de ahí, existen un montón de herramientas que contribuyen a la automatización de las distintas pruebas (Junit, DBUnit, Selenium…). Y todo esto, orquestado por el servidor de integración continua (Hudson, Bamboo…).

Control de versiones

En la siguiente sesión se habló sobre el control de versiones en los proyectos, estableciendo la necesidad de establecer una política de ramas bien definida, para lo que se presentaron varias estrategias.

El conductor, Jose Luis Soria, presentó la serie de tareas necesarias para establecer una política de ramas:
  1. Establecer el modelo de aislamiento: sobre qué rama se realiza un nuevo cambio.
  2. Establecer listas de promoción: definir qué ramas pueden hacer merge a cuáles.
  3. Criterios de calidad.
  4. Establecer un responsable de cada rama, que se encargará de que se mantenga estable.
  5. Establecer permisos.
  6. Estrategia de testeo y construcción automatizada.

Hubo también algún firme impulsor de Git, presentándolo como una alternativa superior a CVS o Subversion, así que habrá que echarle un vistazo.

Agilismo de guerrilla

En esta charla, conducida por Xavi Gost, se habló sobre cómo intruducir el agilismo en una organización. La idea principal que se me quedó es no esperar que vengan de arriba a ofrecértelo, sino ir introduciendo técnicas ágiles en la medida de lo posible en los proyectos.

También se habló sobre la resistencia al cambio por parte de la gente. Resistencia, sobre todo, a los grandes cambios. Por el contrario, si se introducen los cambios de forma disimulada, la gente los adopta sin el miedo que supone presentar a un grupo una nueva metodología o conjunto de prácticas de golpe.

Kanban

Como dijo Xabier Quesada en la presentación, Scrum ha muerto y ahora lo que se lleva es Kanban. Como luego él mismo matizó, esto no es así, puesto que Kanban es algo que todavía se está definiendo.

Xabier, junto con Robin Diamond, nos presentaron Kanban, una nueva metodología basada en Lean. Los principios de Kanban son:
  • Limitar el trabajo en progreso, todo trabajo empzado y no terminado, puesto que está costando dinero.
  • Establecer un flujo continuo de trabajo, que entra por un lado y fluye hasta el final de la cadena de producción.

En la charla contruyeron un tablero Kanban que sirvió para hacernos una idea visual de su funcionamiento.

Historias de usuario

Sesión conducida por Jose Luis Soria, Rodrigo Corral y otro asistente más cuyo nombre no recuerdo :-(. En esta charla se habló de la documentación en los proyectos.

La idea principal sería la de hacer simplemente la documentación que aporte valor al proyecto, bien para el desarrollador o para el usuario, y resistirse a documentar por documentar creando tochos que nadie lee ni actualiza y se quedan obsoletos de forma inmediata.

Se habló mucho de las historias de usuario, representación de un requerimiento a través de una sencilla descripción de la conversación mantenida con un usuario y sus condiciones de aceptación. Una historia de usuario debe tener las siguientes características:
  • Independente
  • Que aporte valor
  • Estimable
  • Negociable
  • Testable
  • Pequeña

De todas las charlas me marché con la sensación de haber aprendido bastante. No siempre tienes la oportunidad de tener delante gente que puede hablar sobre su experiencia en temas en los que tú estás empezando a introducirte.

La pena, no haber podido asistir a otras charlas que también me interesaban. Pero el tener que elegir hace que a las que vayas, lo hagas con el mayor interés.

Un saludo a la organización del Agile Open Spain y a todos sus participantes.

martes, 20 de octubre de 2009

Licencias de Software

Según la Wikipedia, “una licencia de software es un contrato entre el licenciante (autor/titular de los derechos de explotación/distribuidor) y el licenciatario del programa informático (usuario consumidor /usuario profesional o empresa), para utilizar el software cumpliendo una serie de términos y condiciones establecidas dentro de sus cláusulas.

Por tanto, la licencia establece las condiciones bajo las cuáles podemos usar un software determinado.

Puesto que existen una amplia variedad de licencias, voy a exponer a continuación algunas de las más comunes, junto con una breve explicación de lo que estas licencias implican desde el punto de vista del usuario.

GPL

La Licencia Pública General (General Public License) es una licencia de software libre que permite al usuario utilizar un programa licenciado bajo dicha licencia, modificarlo y distribuir las versiones modificadas de éste.

Todo software desarrollado, aunque sólo sea una parte, con material licenciado bajo GPL debe estar disponible para ser compartido de forma gratuita (copyleft), manteniendo los nombres de los autores originales.

El software con licencia GPL carece de garantía, el autor no se hace responsable por el malfuncionamiento del mismo.

Tampoco se puede establecer ningún cobro por las modificaciones realizadas sobre el software.

LGPL

La Licencia Pública General Menor (Lesser General Public License) es una modificación de la licencia GPL, que permite que los desarrolladores utilicen programas bajo la LGPL sin estar obligados a someter el programa final bajo dichas licencias.

LGPL no permite que se realicen versiones comerciales del producto licenciado bajo LGPL. Sin embargo, permite realizar versiones comerciales de un producto final que contenga como herramienta adicional un programa LGPL.

LGPL exige registrar todos los cambios realizados por terceros, a manera de no afectar la reputación del autor original del software.

BSD

La Licencia de Distribución de Software de Berkeley (Berkeley Software Distribution) permite a los programadores utilizar, modificar y distribuir a terceros el código fuente y el código binario del programa de software original con o sin modificaciones bajo licencias de código abierto o comercial.

Esta licencia permite el uso del código fuente en software no libre sin necesidad de mencionar a los autores ni proporcionar el código fuente. Esta licencia sí que establece la renuncia de garantía y la atribución de la autoría sobre trabajos derivados.

MPL

La Licencia Pública de Mozilla (Mozilla Public License) es una licencia de código abierto y sofware libre utilizada por el navegador de Internet Mozilla y sus productos derivados. La MPL deja abierto el camino a una posible reutilización comercial y no libre del software y permite la reutilización del código ni el cambio de licencia.

Apache License

La Licencia Apache es una licencia de software libre que permite al usuario usar el software para cualquier propósito, distribuirlo, modificarlo, y distribuir versiones modificadas de ese software.

La Licencia Apache no exige que las obras derivadas del software se distribuyan usando la misma licencia, ni siquiera que se tengan que distribuir como software libre. La Licencia Apache sólo exige que se mantenga una noticia que informe a los receptores que en la distribución se ha usado código con la Licencia Apache.


Actualmente, existen muchas herramientas que están siguiendo una estrategia de licenciamiento dual de software. Estas proporcionan dos tipos de licencias para el mismo software entre las que puede optar el usuario:
  • Una licencia gratuita de software libre (por ejemplo, GPL) que permite el uso del software a condición de que lo que el cliente desarrolle tambien sea puesto a disposición de otros usuarios libremente.

  • Una licencia de pago comercial que permite que no haya que publicar el código fuente de las aplicaciones desarrolladas.


Referencias:
http://es.wikipedia.org/wiki/Licencia_de_software
http://www.gnu.org/licenses/license-list.es.html
http://www.monografias.com/trabajos55/licencias-de-software/licencias-de-software.shtml
http://es.wikipedia.org/wiki/Apache_License

lunes, 19 de octubre de 2009

Scrum Manager

En los últimos tiempos se viene oyendo hablar mucho sobre metodologías ágiles y, principalmente, sobre Scrum. El creciente interés por Scrum ha hecho florecer una serie de certificaciones al respecto, promovidas por la Scrum Alliance y, por supuesto, de pago. Contra esta tendencia a lucrarse de una metodología que ha florecido dentro de ambientes “Open Source” se han alzado voces que prefieren compartir el conocimiento a través de la comunidad.

Una iniciativa en este sentido es Scrum Manager, que se define como una “comunidad profesional para la gestión flexible de proyectos y organizaciones TIC”. Su objetivo es mejorar los procedimientos y métodos de trabajo de las organizaciones y proyectos de software manteniendo de forma abierta a la comunidad profesional la plataforma de conocimiento Open Knowledge.

Esta plataforma ofrece los siguientes cursos gratuitos sobre Scrum:
  • Introducción a Scrum Manager: Su objetivo es “conocer los principios de los modelos de procesos y las prácticas ágiles, enmarcados en el mapa o marco de situación que les da sentido, y revela las fortalezas y debilidades de cada estrategia: ingeniería, procesos, gestión predictiva y gestión ágil”.

  • Scrum: Su objetivo es “conocer el modelo Scrum: origen del modelo, principios y prácticas que emplea para la gestión y seguimiento ágil del proyecto, sus componentes; junto con las razones y consideraciones de fondo para la implementación del modelo”.

  • Métricas ágiles: Su objetivo es “conocer la razón y finalidad de las métricas en la gestión ágil de proyectos, y evitar errores habituales en el diseño y aplicación de métricas, normalmente por exceso en el número de métricas o en su complejidad, que suele desbordar las necesidades de estimación y seguimiento ágil”.

Estos son cursos ofrecen recursos de aprendizaje como material didáctico y foros. Además, a la conclusión de estos cursos existe una prueba de evaluzación final cuya superación satisfactoria otorga puntos de autoridad dentro de la escala de reconocimiento profesional de Scrum Manager.

Desde aquí quiero aprovechar para felicitar a los responsables de esta iniciativa y agradecerles su esfuerzo.

Referencias:
Scrum Manager

miércoles, 14 de octubre de 2009

Gestionando un proyecto Hibernate desde Maven

Vamos a ver cómo gestionar con Maven un proyecto que utiliza Hibernate.

En primer lugar, vamos a ver cómo configurar las dependencias de Hibernate en Maven. Aquí nos encontramos con un problema, Hibernate depende de la Sun JTA API, que no está disponible en el repositorio central de Maven porque, debido a problemas de licencias, no puede ser distribuida libremente.

Para solucionar este problema existen dos posibles soluciones. La primera es descargar la Sun JTA API de la página web de Sun y despues instalarla en el repositorio local de Maven.

Usaremos el siguiente pom.xml:
<project 
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.roldan.hibernate</groupId>
<artifactId>HibernateMavenProject</artifactId>
<version>0.0.1-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>3.2.6.ga</version>
</dependency>

</dependencies>
</project>

Para instalar la Sun JTA API en el repositorio usaremos la siguiente instrucción desde la línea de comandos:
mvn install:install-file
-DgroupId=javax.transaction
-DartifactId=jta
-Dversion=1.0.1B
-Dpackaging=jar
-Dfile=jta-1_0_1B-classes.zip

La segunda posible solución sería descartar la dependencia de la Sun JTA API que tiene Hibernate y, en su lugar, obtener una implementación alternativa de este API que pueda ser descargada libremente, como la de Geronimo:
<project 
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.roldan.hibernate</groupId>
<artifactId>HibernateMavenProject</artifactId>
<version>0.0.1-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>3.2.6.ga</version>
<exclusions>
<exclusion>
<groupId>javax.transaction</groupId>
<artifactId>jta</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>geronimo-spec</groupId>
<artifactId>geronimo-spec-jta</artifactId>
<version>1.0-M1</version>
</dependency>

</dependencies>
</project>

Una vez resueltas las dependencias de Hibernate en Maven, podemos usar Hibernate en nuestros proyectos. Una herramienta que nos ayudará a simplificar las tareas de administración de estos proyectos es el plugin de Hibernate 3 para Maven, que se puede obtener del repositorio de Codehaus.

Por ejemplo, vamos a usar este plugin para generar el DDL de la base de datos durante el desarrollo, permitiendo reconstruir la base de datos para irnos actualizando a los cambios que se vayan produciendo:
<project>

<repositories>
<repository>
<id>codehaus</id>
<name>Maven Codehaus repository</name>
<url>http://repository.codehaus.org/</url>
</repository>
</repositories>

<build>
<extensions>
<extension>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.6</version>
</extension>
</extensions>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>hibernate3-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<componentProperties>
<drop>true</drop>
<outputfilename>schema.sql</outputfilename>
</componentProperties>
</configuration>
</plugin>
</plugins>
</build>
</project>

Para lanzar la ejecución de esta tarea de actualización de la base de datos, usamos el comando:
mvn org.codehaus.mojo:hibernate3-maven-plugin:2.2:hbm2ddl

martes, 6 de octubre de 2009

Hacer un release de un proyecto con Maven

A la hora de hacer un release de un proyecto que estamos gestionando con Maven y Subversion podemos seguir los siguientes pasos:
  • Cambiar la versión en el pom.xml del proyecto y quitar la etiqueta SNAPSHOT.
  • Hacer commit del pom.xml.
  • Etiquetar la versión del código en el repositorio de Subversion.
  • Cambiar la version en el pom.xml para dejar la siguiente versión: 0.0.2-SNAPSHOT.
  • Hacer commit de los pom.xml.

Si además, en vez de sólo uno, tenemos varios proyectos, el trabajo se multiplica.

Para simplificar estas tareas, se puede hacer uso de un plugin de Maven, el Maven Release Plugin. Para ello, primero debemos configurar las propiedades del sistema de control de versiones que estamos usando. Esto se hace en el bloque scm del pom.xml:
<scm>
<url>svn://localhost/trunk/SimpleProject</url>
<developerConnection>
scm:svn:svn://localhost/trunk/SimpleProject
</developerConnection>
</scm>

Ahora, incluimos en el pom.xml del proyecto la configuración para el Maven Release Plugin. Vamos a indicar en que ruta se deben dejar los etiquetas de las releases que realicemos:
<project>

<build>
<plugins>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.0-beta-7</version>
<configuration>
<tagBase>svn://localhost/tags/releases</tagBase>
</configuration>
</plugin>

</plugins>
</build>

</project>

A la hora de hacer la release he experimentado fallos relacionados con el directorio target, puesto que este es un directorio que se elimina cada vez que se hace un clean, lo cual genera conflictos entre las versiones del proyecto en Subversion. Puesto que es un directorio cuyo contenido se genera automáticamente en la fase de construcción del proyecto, no es necesario que lo incluyamos en el sistema de control de versiones. Vamos a indicar en Eclipse que este directorio sea ignorado por Subversion, desde la ventana Preferences:

En este momento, ya se podría hacer una release del proyecto mediante el siguiente comando que se ejecutaría dentro del directorio del proyecto:
mvn -Djorge=jorgepassword release:clean release:prepare

La ejecución de este comando nos preguntará por la versión de la release que estamos realizando, por el nombre de la etiqueta para esta release y por la siguiente versión del proyecto después de esta release. En nuestro caso, dejaremos las opciones por defecto:
What is the release version for 
"Unnamed - com.roldan:SimpleProject:jar:0.0.2-SNAPSHOT"?
(com.roldan:SimpleProject) 0.0.2: :
What is SCM release tag or label for
"Unnamed - com.roldan:SimpleProject:jar:0.0.2-SNAPSHOT"?
(com.roldan:SimpleProject) SimpleProject-0.0.2: :
What is the new development version for
"Unnamed - com.roldan:SimpleProject:jar:0.0.2-SNAPSHOT"?
(com.roldan:SimpleProject) 0.0.3-SNAPSHOT: :

Al finalizar, habremos creado la release del proyecto:

Referencias:
http://maven.apache.org/plugins/maven-release-plugin/index.html
http://weblogs.java.net/blog/2008/08/31/using-maven-release-plugin
http://jmbeas.blogspot.com/2009/03/versionado-automatico-con-maven.html

jueves, 1 de octubre de 2009

Herramientas de análisis de calidad del código

Existen muchas herramientas que nos permiten analizar el código desarrollado y parecen ser ampliamente usadas. Me había propuesto escribir un artículo describiendo el uso de algunas de ellas, pero visto que esta información ya existe y es fácilmente localizable en Internet, me voy a limitar a enumerar estas herramientas y hacer una breve descripción de para qué sirve cada una.

Las herramientas sobre las que voy a hablar son:
  • Checkstyle
  • PMD
  • Findbugs
  • JDepend
  • JavaNCSS
  • Cobertura

Checkstyle (http://checkstyle.sourceforge.net/)

Checkstyle ayuda a escribir código que se adhiera a unas convenciones de codificación determinadas. Además, en las últimas versiones se le han añadido nuevas características que permiten también encontrar problemas en el diseño de las clases, encontrar código duplicado o buscar patrones de error conocidos.

Checkstyle tiene plugins que permiten que sea usado desde cualquier IDE, como Eclipse (http://eclipse-cs.sourceforge.net/), resaltando sobre el código los errores encontrados por el analizador. También poseee un plugin para Maven 2 (http://maven.apache.org/plugins/maven-checkstyle-plugin/) que permite generar informe sobre lor errores encontrados.

PMD (http://pmd.sourceforge.net/)

PMD busca en el código fuente ciertos patrones de error, código no usado, código no óptimo, expresiones demasiado complicadas y código duplicado.

Podemos usarlo tanto en Eclipse (http://pmd.sourceforge.net/integrations.html#eclipse) como en Maven (http://maven.apache.org/plugins/maven-pmd-plugin/project-info.html).

Findbugs (http://findbugs.sourceforge.net/)

Se trata de otra herramienta que realiza análisis estático de código en busca de errores.

También puede ser usado en Eclipse (http://findbugs.sourceforge.net/manual/eclipse.html) como en Maven (http://mojo.codehaus.org/findbugs-maven-plugin/2.0.1/).

JDepend (http://clarkware.com/software/JDepend.html)

Jdepend proporciona métricas de cálidad entre los paquetes de un proyecto en términos de su extensibilidad, reusabilidad, y mantenibilidad.

Como las herramientas anteriores, se puede usar en Eclipse (http://andrei.gmxhome.de/jdepend4eclipse/) y en Maven (http://mojo.codehaus.org/jdepend-maven-plugin/).

JavaNCSS (http://www.kclee.de/clemens/java/javancss/)

Esta herramienta permite recoger métricas sobre el código fuente, como el número de líneas, paquetes, clases o métodos.

Al igual que todas las herramientas anteriores, se puede susar en Eclipse (http://freshmeat.net/projects/jncss4eclipse/) y en Maven (http://mojo.codehaus.org/javancss-maven-plugin/dependencies.html).

Cobertura (http://cobertura.sourceforge.net/)

Esta herramienta permite calcular la cantidad de código al que acceden los tests.

En este caso, no se dispone de un plugin para Eclipse, pero si que podemos usar esta herramienta desde Maven (http://mojo.codehaus.org/cobertura-maven-plugin/).


Os animo a que probéis estas herramientas. ¿Conocéis alguna más que pueda resultar útil para el desarrollo de un proyecto Java?