2010-12-28 11 views
6

Tengo una aplicación GWT construida en Maven, ahora tratado de realizar un simple análisis de GWT como abajo:¿Cómo puedo usar las pruebas maven y jUnit juntas?

public class GwtTestLaughter extends GWTTestCase { 

    /** 
    * Specifies a module to use when running this test case. The returned 
    * module must include the source for this class. 
    * 
    * @see com.google.gwt.junit.client.GWTTestCase#getModuleName() 
    */ 
    @Override 
    public String getModuleName() { 
     return "com.sample.services.joker.laughter.Laughter"; 
    } 

    /** 
    * Add as many tests as you like 
    */ 
    public void testSimple() { 
     assertTrue(true); 
    } 
} 

y en el archivo pom.xml, configurado el GWT-maven-plugin y experto-surefire- plugin como bramido:

<plugin> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>gwt-maven-plugin</artifactId> 
    <version>2.1.0-1</version> 
    <configuration> 
     <!-- Use the 'war' directory for GWT hosted mode --> 
     <output>${basedir}/war</output> 
     <webXml>${basedir}/war/WEB-INF/web.xml</webXml> 
     <runTarget>index.html</runTarget> 
     <!-- Make sure the GWT compiler uses Xerces --> 
    <extraJvmArgs> 
    -Dgwt.style=DETAILED -Xmx512M -Xss1024k -XX:MaxPermSize=128m -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl -Dlogback.configurationFile=./src/test/resources/logback-test.xml 
    </extraJvmArgs> 
</configuration> 
<executions> 
    <execution> 
    <goals> 
     <goal>compile</goal> 
     <goal>test</goal> 
    </goals> 
    </execution> 
</executions> 

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-surefire-plugin</artifactId> 
    <configuration> 
     <useFile>false</useFile> 
     <forkMode>once</forkMode> 
     <argLine>-Xmx128m</argLine> 
     <systemPropertyVariable> 
     <property> 
      <name>log4j.configuration</name> 
      <value>log4j.properties</value> 
     </property> 
     </systemPropertyVariables> 
    </configuration> 
    <executions> 
     <execution> 
      <id>unit-test</id> 
      <phase>test</phase> 
      <goals> 
      <goal>test</goal> 
      </goals> 
      <configuration> 
       <skip>false</skip> 
       <includes> 
       <include>**/*Test.java</include> 
       <includes> 
       <excludes> 
       <exclude>**/GwtTest*.java</exclude> 
       </excludes> 
      </configuration> 
     </execution> 
    <execution> 
     <id>integration-test</id> 
     <phase>integration-test</phase> 
     <goals> 
     <goal>test</goal> 
     </goals> 
     <configuration> 
      <skip>true</skip> 
      <includes> 
      <include>**/GwtTest*.java</include> 
      <includes> 
      <excludes> 
      <exclude>**/*Test.java</exclude> 
      </excludes> 
     </configuration> 
    </execution> 
    <executions> 
    </plugin> 

Cuando me encontré con 'mvn test' en la línea de comandos, que puede ver sólo las pruebas normales Junit corrieron (el que tiene nombre de archivo Test.java), cuando ejecuté 'mvn integration-test', todavía veo todas las pruebas, incluidas la prueba normal de Junit y la prueba Gwt (las que tienen el nombre de archivo GwtTest .java) ejecutadas.

Pregunta 1:

¿Cómo puedo totalmente excluir a correr la prueba Junit normal durante la prueba para la integración? o eso es imposible? Debido a que en el ciclo de vida de maven predeterminado, la fase de prueba se define para existir antes de la prueba de integración, no hay forma de omitir la fase de prueba para ejecutar una prueba de integración pura.

Desde que mezclé todo el código de pruebas bajo/carpeta src/test/java, cuando me encontré con la 'integración-mvn test' y observaba la salida en la ventana de línea de comandos, vi lo siguiente:

[INFO] running com.sample.services.joker.laughter.client.GwtTestLaughter 
.. 
[INFO] Validating newly compiled units 
[INFO] [ERROR] Errors in 'file:...src/test/java/com/sample/joker/laughter/client/file1Test.java'.. 
[INFO] [ERROR] Line 42: No source code is available for type...; did you forget to inherit a required module? 
... 

Pregunta 2:

No entiendo esto, la prueba gwt es muy simple, por qué validaría un * Test.java no relacionado y buscaría su código fuente. aunque finalmente se desarrolló correctamente con la prueba aprobada, ¿cómo puedo deshacerme de esos desagradables mensajes de error?

Tal vez debería olvidarme del plugin gwt-mavin y seguir con las pruebas clásicas de Juint.

Respuesta

1

puedo ayudar con la pregunta 1. Para pasar las pruebas de funcionamiento:

mvn (goals) -Dmaven.test.skip=true 

Esto hará caso omiso de las pruebas JUnit.

En cuanto a la pregunta 2, JUnit clásico puede ser el camino a seguir. No estoy muy familiarizado con GWT, pero ¿tiene anotaciones de prueba (@test)? ¿Y qué está en la línea 42 que es error?

2

Debe añadir archivos src en la ruta de clase de esta manera:

<plugin> 
<artifactId>maven-surefire-plugin</artifactId> 
<version>2.6</version> 
<configuration> 
    <additionalClasspathElements> 
    <additionalClasspathElement> 
     ${project.build.sourceDirectory} 
    </additionalClasspathElement> 
    <additionalClasspathElement> 
     ${project.build.testSourceDirectory} 
    </additionalClasspathElement> 
    </additionalClasspathElements> 
    <useManifestOnlyJar>false</useManifestOnlyJar> 
    <forkMode>always</forkMode> 
    <systemProperties> 
    <property> 
     <name>gwt.args</name> 
     <value>-out \${webAppDirectory}</value> 
    </property> 
    </systemProperties> 
</configuration> 

Reference

1

Sólo un lado para que, en la mayoría de los proyectos no triviales que he estado involucrado con, hay un prejuicio extremo hacia JUnit por dos razones. La primera es que GWTUnit requiere un giro del contexto javascript que es lento, dolorosamente lento, en comparación con una prueba JUnit.En segundo lugar, no debería haber demasiadas cosas que estés escribiendo que requieran un contexto de Javascript para probar en función de tu diseño y estructura de código; principalmente por el problema 1, pero también recuerde que está escribiendo algo con una vista de GWT en este momento, pero realmente quiere que eso sea independiente de la tecnología de visualización tanto como sea posible. De esta forma, cuando Swing haga su triunfante regreso a la eminencia, podrá realizar el cambio de manera mucho más fácil. Estoy bromeando, un escenario más probable sería portar a Android o quién sabe qué más en el futuro.

Básicamente, GWTUnit es muy lento de ejecutar debido al entorno que tiene que girar, y en realidad, usted debe ser (en mi humilde opinión) teniendo en cuenta su lógica de negocio para que no esté eternamente acoplado a cualquiera ver la tecnología de representación. En mi opinión, la mayor parte de su lógica que puede separarse del mundo de widgets y paneles de UI puro, ya sea lógica de tipo de flujo de control, lógica de validación o cualquier otra cosa que no sea simplemente poner cosas en la pantalla y obtener valores dentro y fuera de ellos. Todo lo demás debería estar fuera de esas clases en un proyecto más grande, y tomar objetos como insumos que no estén relacionados con GWT de ninguna manera. Si lo hace, puede usar la gran mayoría de su aplicación, que es ridículamente rápida, y no tendrá que esperar para siempre (en un gran proyecto, una gran cobertura con GWTUnit llevaría horas, tal vez días). No voy a hablar sobre qué tan bueno es mantener una base de código cubierta de prueba sólida.

Esta diatriba se basa en la última tarea que hice aquí en mi trabajo actual, había un conjunto de lógica de negocios que se terminó con la capa de vista que tenía (al final de la desenrollado y construcción de un completo conjunto de pruebas unitarias) 178 escenarios diferentes que todos tuvieron que ejecutarse correctamente. Esto era algo que nunca debería haber sabido que se estaba ejecutando en GWT, pero era corto y estaba plagado de referencias a las clases de tecnología de vista. De hecho, esto era algo que ya estaba escrito para una versión anterior del software y no había cambiado mucho, pero ellos envolvieron la lógica en esa capa de vista (que era Swing). El nuevo equipo acaba de repetir los pecados del equipo anterior y, debido a eso, esta sección de códigos requirió horas de prueba a mano, que estoy seguro no cubrió el 100% de los escenarios, a diferencia de una prueba rápida de varias segundas unidades. que los ejecuta a todos.

7

Hola entiendo su problema y la probable solución radica en esta GWT-maven-plugin de página de documentación: https://gwt-maven-plugin.github.io/gwt-maven-plugin/user-guide/testing.html

De acuerdo con la documentación del plugin:

por la intención: El objetivo de 'prueba' está obligado de forma predeterminada, a la fase de prueba de integración y GWTTestCase no se considera una prueba unitaria, ya que requieren la ejecución de todo el Módulo GWT.

Para ejecutar las pruebas basadas en Surefire y gwt-maven-plugin (para las pruebas regulares de JUnit en el servidor con Surefire, y para las pruebas de modelo y controlador de cliente con GWT) necesita distinguir estas pruebas entre sí. Esto se hace usando una convención de nomenclatura.

Puede configurar el plugin Surefire (responsable de ejecutar pruebas durante la compilación de maven) para omitir las pruebas de Gwt usando algunos patrones de nomenclatura.

Una manera más simple de separar las pruebas clásicas y GWT es nombrar las últimas pruebas GwtTest "Something" .java. Como surefire busca pruebas que se llaman Something "Test" .java de forma predeterminada, se ignorarán durante la fase de prueba.

De forma predeterminada, el plugin gwt-maven utiliza GwtTest * .java como patrón de inclusión para que dichas pruebas no coincidan con el patrón Surefire estándar. Usando esta convención, no tiene que cambiar su configuración.

Cuestiones relacionadas