Integration tests with gradle

Question

I am new to the gradle tool, and I am trying to add the support for running integration test using the jetty plugin in gradle. I came across two posts, one and two, but the difference in my approach is, that I am not using a separate source set for integration tests. My integration tests are named following the pattern,

" **/ITCase*.*".

My project has 4 child modules, and I am setting up the integration test for the services modules. Using the example here , I set up the jetty configuration:

[jettyRun, jettyStop]*.stopPort = 8006
[jettyRun,jettyStop]*.stopKey = 'STOP'
jettyRun {
   classpath=configurations.compile
}

task integrationTest(type: Test, dependsOn: "test" ) {
include '**/*ITCase*.*'
println 'Starting the embedded jetty'
doFirst {
    jettyRun.daemon = true
    jettyRun.scanIntervalSeconds = 0
    jettyRun.execute()
}
doLast {
    jettyStop.execute()
    println 'Stopping the embedded jetty'
}

}

"test" is a task defined in the parent project's build.gradle.

When I run the command, gradle war integrationTest, the integration tests fails as it cannot find the context listener in the services project. A snippet of the error message is as follows:

:services:integrationTest (Thread[Daemon Thread 14,5,main]) started.
:services:integrationTest
Executing task ':services:integrationTest' (up-to-date check took 0.026 secs) due to:
  No history is available.
Starting the embedded jetty
Executing task ':services:jettyRun' (up-to-date check took 0.0 secs) due to:
  Task has not declared any outputs.
Configuring Jetty for project ':services'
Webapp source directory = E:\Workspace\project\services\src\main\webapp
Reload Mechanic: automatic
web.xml file = E:\Workspace\project\services\src\main\webapp\WEB-INF\web.xml
Context path = /services
Tmp directory =  determined at runtime
Web defaults = org/mortbay/jetty/webapp/webdefault.xml
Web overrides =  none
Webapp directory = E:\Workspace\project\services\src\main\webapp
Starting jetty 6.1.25 ...
jetty-6.1.25
Could not instantiate listener com.db.project.services.ProjectServletContextListener
java.lang.ClassNotFoundException: com.db.project.services.ProjectServletContextListener
    at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
    at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:401)
    at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:363)
    at org.mortbay.jetty.handler.ContextHandler.loadClass(ContextHandler.java:1101)
    at org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:630)
    at org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:368)
    at org.mortbay.jetty.plus.webapp.AbstractConfiguration.initWebXmlElement(AbstractConfiguration.java:190)
    at org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:289)

Any help on this is appreciated. Thanks in advance

score 0 · Accepted Answer · answered Jan 04 '14 at 23:21

0

I think the root cause for your error message is, that the classpath of your jetty task does not contain the projects production code but just its compile classpath. To get this working, removing the classpath configuration from the snippet should do the trick. The jetty plugin already does that for you.

Another side note: In general it is considered to be bad practice to execute a task by running 'task.execute'. Instead you should use Task#dependsOn & Task#finalizedBy. Imagine one of your tests are failing. then the doLast block is never executed and your jetty is never stopped.

cheers, René

answered Jan 04 '14 at 23:21

Rene Groeschke

27,999
10
69
78

Thanks Rene, now I don't see that error anymore. But it looks like it is still not able to locate the war, all the integration tests return a 404 error. Is there some additional configuration to point it to the war? – Sriprabha Jan 06 '14 at 14:16
can you run your build with info logging enabled and check manually if you can reach your webapp? cheers, – Rene Groeschke Jan 06 '14 at 14:29
I noted an error message after the jetty start up:"failed ContextHandlerCollection@5d3b9a4e: java.lang.NoClassDefFoundError: com/sun/jersey/spi/container/WebApplication failed HandlerCollection@6766b0f5: java.lang.NoClassDefFoundError: com/sun/jersey/spi/container/WebApplication", I do have all the jersey dependencies in my dependency block, but jetty is not able to locate these, and I think that is why the tests are failing. – Sriprabha Jan 06 '14 at 14:50
can you post your dependencies block of your build.gradle file and double check the war contains the classes listed in the NoClassDefFoundError? – Rene Groeschke Jan 06 '14 at 16:36
The missing class (com/sun/jersey/spi/container/WebApplication) is in a package, jersey-server, that is one of the transitive dependencies of com.sun.jersey:jersey-servlet:1.17.1, gradle is not pulling in the transitive dependency of this package and that is why I see that error. – Sriprabha Jan 06 '14 at 18:38
please provide the dependency section to see why the transitive dependency is not pulled in – Rene Groeschke Jan 06 '14 at 18:44
services build.gradle(splitting it up due to char limit) dependencies { compile 'com.sun.jersey:jerseyjson:1.13', 'com.sun.jersey:jerseyservlet:1.17.1', 'com.google.inject:guice:3.0','com.google.inject.extensions:guice-servlet:3.0','javax.servlet:servlet-api:3.0-alpha-1', 'com.sun.jersey.contribs:jersey-guice:1.13', 'com.google.collections:google-collections:1.0', 'com.googlecode.gwtupload:gwtupload:0.6.4', 'com.jayway.restassured:rest-assured:1.6.2','com.sun.jersey:jersey-core:1.17.1','com.sun.jersey:jersey-client:1.9.1' – Sriprabha Jan 06 '14 at 18:57
providedCompile project(':shared'),project(':model'),project(':persistence') compile 'org.hibernate:hibernate-validator:4.1.0.Final','org.codehaus.jackson:jackson-core-asl:1.9.4' testCompile libraries.junit,libraries.mockito_all,'com.googlecode.openpojo:openpojo:0.4.2' – Sriprabha Jan 06 '14 at 18:57
It looks like a bug in gradle. The transitive dependency jersey-server is declared in the "default" profile section of the pom of jersey-servlet. Gradle does not download these transitive dependencies that are declared in the profile section of the POM, as described here: http://issues.gradle.org/browse/GRADLE-1997 . Only workaround right now would be to explicitly specify the transitive dependencies. – Sriprabha Jan 06 '14 at 21:36

Integration tests with gradle

1 Answers1