I am using karate 0.9.2 with gradle. My project requires to have all karate tests inside src/main/java. So I configured the gradle dependency as ‘compile’ instead of ‘testCompile’ and also modified the sourceSets to point to main instead of test. When I ran my runner class with above configuration I got empty test suite message.
build.gradle snippet:
compile 'com.intuit.karate:karate-junit4:0.9.3'
compile 'com.intuit.karate:karate-apache:0.9.3'
sourceSets {
test {
resources {
srcDir file('src/main/java')
exclude '**/*.java'
}
}
}
Additionally, I have is to run the karate tests from the deployable project jar. Please point me the resources I can refer to achieve the same.
Not something we directly support but teams have done this in Spring Boot etc. It should be possible, see if this thread helps: https://github.com/intuit/karate/issues/520
Also you may not need JUnit also: https://github.com/intuit/karate/issues/427
And see the sample project in this ticket as an example: https://github.com/intuit/karate/issues/529
EDIT - in 1.0 onwards we hope that class-loading from spring-boot JAR files is more reliable: https://github.com/intuit/karate/issues/751
Related
I have gradle project with Kotlin plugin.
In my project I uses groovy and Spock for tests.
One of utility classes used in tests in written in Kotlin and I put it to src/test/kotlin
I'm trying to use this class from groovy tests (Spock specification), I see that "compileTestKotlin" task runs first and compiles my utility class, but still "compileTestGroovy" fails, because it does not see it.
How can I fix this situation?
How to add build/classes/kotlin/test/ to the compilation classpath of groovy tests?
The issue is that by default compileTestGroovy doesn't include build/classes/kotlin/test folder, so your Kotlin util class cannot be seen from Groovy tests.
In order to fix it you can manually add Kotlin test sources to compileTestGroovy's classpath. Add the following to your build.gradle:
compileTestGroovy.classpath += files(compileTestKotlin.destinationDir)
// in more recent versions it must be
compileTestGroovy.classpath += files(compileTestKotlin.destinationDirectory)
If your build file is build.gradle.kts, add the following
// make groovy test code depend on kotlin test code
tasks.named<GroovyCompile>("compileTestGroovy") {
classpath += files(tasks.compileTestKotlin)
}
Is it possible to run a TestNG test suite that is embedded in a JAR file via a Gradle test task?
My project includes JARed bundles of TestNG tests that have an embedded testng.xml file defining which tests should be run in the JAR. Is it possible for Gradle to refer to this embedded XML when running the TestNG tests?
From the command line I use the xmlpathinjar option.
I dont think it can be done using the Gradle TestNG task. I couldn't find any such support in the TestNGOptions
Instead of using
test{
useTestNG()
}
you could try going through this post on SO How can I tell Gradle to use my testng.xml file for Test Classes and Ordering? and maybe employ the approach detailed here https://stackoverflow.com/a/28868416
But when you are using a custom Gradle task to run your TestNG tests, please make sure that you add a reference to the ExitCodeListener
Here's a sample
task ('myTask', type: JavaExec) {
main = 'org.testng.TestNG'
classpath = sourceSets.main.runtimeClasspath + sourceSets.test.runtimeClasspath
args = ["-xmlpathinjar", "suites/mysuite.xml", "-listener", "org.testng.TestNG\$ExitCodeListener"]
}
More details on why the ExitCodeListener needs to be referred, can be found here
It's configured the same here as it is everywhere else. In fact I use an import for configuring integration tests. I've done everything I can think of including a rename of local integration test tasks and configurations, including looking at the dependency tree, including running with --debug. Yet for some reason Gradle insists that the property integrationTest doesn't exist on the sourceSet for an inter-project dependency:
integrationTestCompile project(':components:things-components:abc-stuff').sourceSets.integrationTest.output
...now I'm not particularly fond of this syntax and I've already griped up a storm about inter-project test dependencies and how they should be in a test utility component. However, I'm doing it this way because this appears to be what IntelliJ will accept. Writing like this causes trouble:
integrationTestCompile project(path: ':components:things-components:abc-stuff', configuration: 'integrationTest')
How can I figure this out? I just don't get why only one project has this issue.
For the record, I've also tried:
integrationTestCompile project(path: ':components:things-components:abc-stuff', configuration: 'integrationTestCompile')
The issue is that Gradle hasn't been told to make a jar for you that you can consume in your other project.
integrationTestCompile project(':components:things-components:abc-stuff').sourceSets.integrationTest.output
Gets the classFiles and the dependencies, thats why its working using that notation. If you want to use the configuration notation you will need to tell gradle to publish a jar on the integrationTest. The jar doesn't have to be published to a repository, but will be used for the internal builds.
You can do this by doing:
configurations {
integrationTest
}
task integrationTestJar (type: Jar) {
baseName = "${project.name}-integ-test"
from sourceSets.integrationTest.output
}
artifacts {
integrationTest integrationTestJar
}
If you end up doing this in a log of projects, I would recommend writing a quick plugin that does this for you.
The problem I was having, was that I wanted to include test classpath resources in SpringBoot's bootRun gradle task. Why? So that I could use a test profile with test resources, to mock integration points.
What I tried:
The spring boot documentation only offers the addResources = true option (I tried using customConfiguration as per the similar bootRepackage configuration, to no avail)
No additional options are visible by looking at the BootRunTask source code
The equivalent maven plugin has a plethora of options, including useTestClasspath (which isn't mirrored in the gradle version)
I came across the following solution, which solved this issue for me.
Basically, the BootRunTask extends the standard JavaExec task, which offers a classpath option. So, you can add the test classpath resources by using the following gradle configuration:
bootRun {
classpath = sourceSets.test.runtimeClasspath
}
We have a web service project that relies on Netflix's Eureka and it has a dependency on Jersey client 1.x.
Our project is using gradle and in the project we have our src, unit, integration, and functional tests. For our functional tests we have a jar that we import in the testCompile gradle section that wraps a Jersey client to send requests to the web service.
Now my question is how can I get the netflix Jersey client dependency to be ignored in the testCompile so I can use the new Jersey 2.x client for the functional tests?
Build Scripts below:
Main service build script excerpt:
dependencies {
compile 'com.netflix.eureka:eureka-client:1.1.97'
compile 'com.sun.jersey:jersey-bundle:1.18'
testCompile 'some.domain:service-test-client:1.0.1'
}
service test client relevant parts:
dependencies {
compile 'org.glassfish.jersey.core:jersey-client:2.19'
compile 'org.glassfish.jersey.connectors:jeresey-apache-connector:2.19'
}
Relevant parts of the Eureka Client gradle script from github:
ext {
githubProjectName = 'eureka'
awsVersion='1.9.3'
servletVersion='2.5'
jerseyVersion='1.11'
governatorVersion='1.3.3'
archaiusVersion='0.6.5'
blitzVersion='1.34'
mockitoVersion='1.9.5'
junit_version='4.10'
mockserverVersion='3.9.2'
jetty_version='7.2.0.v20101020'
}
dependencies {
compile "com.sun.jersey:jersey-core:$jerseyVersion"
compile "com.sun.jersey:jersey-client:$jerseyVersion"
compile 'com.sun.jersey.contribs:jersey-apache-client4:1.11'
compile 'org.apache.httpcomponents:httpclient:4.2.1'
}
With the above setup I get method not found errors because when the tests are running some of the jersey 1.x classes are taking precedence over the classes brought in with the test-client jar.
You can use gradle dependency monitoring to find out what libraries are bringing in jersey.
./gradlew dependencies
You can pipe that into a file, and less your way into finding out who's bringing in jersey 1.*.
Then, just exclude it from those specifically, and compile your own:
compile("com.example.library:artifactId:x.y.z"){
exclude group:'org.glassfish.jersey', module:jersey-common
}
compile('org.glassfish.jersey.core:jersey-common:2.4.1')
I got same problem with jersey 1.x vs glassfish 2.x with Eureka (but with Spring Cloud). I'm trying this:
compile ("org.springframework.cloud:spring-cloud-starter-eureka:1.0.0.RELEASE")
{
exclude group:'com.sun.jersey', module: 'jsr311-api'
}
But then Eureka doesn't work for me...
I think I will try to switch to Eureka 2.0 with different jersey, but without spring cloud:
https://github.com/Netflix/eureka/wiki/Eureka-2.0-Architecture-Overview
http://mvnrepository.com/artifact/com.netflix.eureka check Eureka2 dependencies
maybe you can use them?