Integrar Unidades de Test
A menos que las unidades de testeo automatizadas estén claramente integradas en el proceso de construcción, los desarrolladores tienden a saltarselas. Maven elimina cualquier excusa para no testear haciéndolo fácil. Todo que lo que tienes que hacer es decirle a Maven donde encontrar tus clases de tests. Aquí están los pasos:
- En project.xml, añade el elemento unitTestSourceDirectory directamente debajo del elemento sourceDirectory:
...
</sourceDirectory>
<unitTestSourceDirectory>
${basedir}/src/test
</unitTestSourceDirectory>
...
- Crea una clase de test llamada BoxTest: con el nombre de fichero c:\daven\src\java\smartsoft\daven\BoxTest.java:
package smartsoft.daven;
import junit.framework.TestCase;
public class BoxTest extends TestCase{
public void test1(){
Box b = new Box(2,2);
assertEquals(4,b.getArea());
}
}
- Ejecuta de nuevo el goal java:jar, que indirectamente llama a los goals test:compile y test:test:
maven java:jar
La salida de la consola debería parecerse a esto:
C:\daven>
maven jar
java:prepare-filesystem:
java:compile:
[echo] Compiling to C:\daven/target/classes
java:jar-resources:
test:prepare-filesystem:
test:test-resources:
test:compile:
[javac] Compiling 1 source file to C:\daven\target\test-classes
test:test:
[junit] dir attribute ignored if running same VM
[junit] Running smartsoft.daven.BoxTest
[junit] Tests run: 1, Failures: 0, Errors: 0
BUILD SUCCESSFUL
Total time: 10 seconds
Si algún test falla, puedes ver los informes generados en el directorio targets/test-reports.
El Repositorio de Maven Organiza los Ficheros Jar
La mayoría de los proyectos utilizan librerías de terceras partes en forma de ficheros Jar. El repositorio es un mecanismo espacial de Maven para organizar los ficheros Jar y otras dependencias que utilizan tus contrucciones. (Maven también utiliza el término artefacto para referirse a las dependencias). El repositorio esencialmente es una carpeta con un estructura específica para Maven, y soluciona dos problemas. Primero, proporciona una localización centralizada para todos los ficheros Jar y otras dependencias que necesita tu proceso de construcción. Segundo, es un ayuda con los problemas de versiones proponiendo una convención de nombrado. Abajo tienes la estructura de un repositorio Maven:
<USER_HOME>/repository
jdo
jars
kodo-1.1.jar
kodo-1.2.jar
jdoInterfaces-1.0.jar
filters
jars
jxFilter-1.0.jar
jxFilter-1.1.jar
O, más generalmente:
<USER_HOME>/repository/groupId/type/artifactId-version.ext
Así, para kodo-1.1.jar, jdo es el groupId, jar es el type de dependencia, kodo es el artifactId, y 1.1 es la version. Estos elementos se representarán en tu POM.
Maven soporta un repositorio local y un repositorio de red compartido. Primero chequea el repositorio local, y si no encuentra el fichero Jar, chequea el repositorio compartido. Maven almacena los ficheros Jar del directorio compartido en el directorio local.
Determinar la Dependencias de un Proyecto
La característica del repositorio de Maven está muy relacionada con la forma en que maven trata las dependencias del proyecto. En Ant, tienes que crear un classpath para indicar los ficheros Jar de los que depende tu proyecto, mientras que Maven utiliza el elemento dependencies en el fichero project.xml para este propósito.
Añade una dependencia de un fichero Jar a tu proyecto para ver como funcina esto. Añade el siguiente bloque de código al fichero project.xml, debajo del elemento currentVersion pero encima del elemento build:
...
<currentVersion>1.0</currentVersion>
<dependencies>
<dependency>
<groupId>jdo</groupId>
<artifactId>kodo</artifactId>
<version>2.5.2</version>
</dependency>
</dependencies>
<build>
...
Para que esta etiqueta funcione, debe existir el siguiente fichero Jar:
<USER_HOME>/repository/jdo/jars/kodo-2.5.2.jar
Varios goals utilizan la etiqueta dependency. Por ejemplo, el goal compile la utiliza para generar el classpath, y el goal deploy la utiliza para determinar qué fichero Jar copiar.
Tutoriales
