I'm having a simple junit test task.
task testSanity(type: Test, dependsOn: testClasses) {
def springInstrumentJarPath = project.configurations.compile.find { it.name.startsWith("spring- instrument") }
jvmArgs '-javaagent:' + springInstrumentJarPath
exclude '**/*TimeBaseTest*'
exclude '**/*SuiteTests*'
}
Problem is i added a new xml file for my ehcache at:
/src/main/webapp/WEB-INF/classes/ehcache.xml
And all my test fails since junit is not able to find the file.
How can I define this in the gradle task?
Thanks.
src/main/webapp should only contain files that aren't used from Java code (more precisely, files that aren't loaded by a class loader). Java resources should instead go into src/main/resources. Hence, moving the file to src/main/resources/ehcache.xml should solve the problem.
Related
How do we make mvn build or Gradle build to take test cases from the main package if we have written test cases in the main package?
In gradle you just redefine the main and test sourceSets with filters in your build.gradle file to exclude / include the test files in the specific phase of the build.
For example the file named LibraryTest.java will be compiled and executed only during the test phase.
sourceSets {
main {
java {
srcDirs = ['src/main/java']
exclude '**/*Test.java'
}
}
test {
java {
srcDirs = ["src/main/java"]
include '**/*Test.java'
}
}
}
you can write your test cases where ever you want, BUT!
It is not a recommended practice, so if you are using maven/gradle - they will give you dedicated folder/path for writing test cases.
The reason why it is not recommended - is maven/gradle provides lot of plugins which will help you to run your test cases, generate reports for those test cases, control the build if test cases fails.
All these plugins will look up at the default path, so if you decide to use a different path rather than default - you need to change the path for test cases in all your plugin.
so if you choose to use your own path for test resources, you are just adding overhead of additional configuration changes.
I'm new to gradle, trying to set up an old project (which used ant). Project setup is fine, though rather complex because of some ugly requirements where different resources need to go multiple different places, with some needing to be filtered according to different properties files etc..
Anyway, I am now trying to set up testing. The problem is that the tests require a hibernate.properties file that is different to the one used in the main project. So, I added a reference to the relevant resource folder:
sourceSets {
test {
resources {
srcDirs "${outputDir}/test/generated-src"
}
}
}
The hibernate.properties file for the main project is in:
sourceSets {
main {
resources {
srcDirs "${outputDir}/generated-src"
}
}
}
(The reason they are not just in src/main/resources etc, is that they required some special handling before they can be used.)
Using "gradle test" works (probably by luck), because it uses the hibernate.properties from the test folder.
But, running junit tests from Eclipse does not work, because in Eclipse the "${outputDir}/test/generated-src" folder gets added to the classpath AFTER the main one. So the tests find the main hibernate.properties, and fail...
I tried to mess around with reordering the classpath for Eclipse, but failed. A workaround is to manually change the order in Eclipse->project properties->Build path->Order and export, but I would like a proper solution.
I'm thinking this probably isn't an unknown problem, and there is probably a proper gradle solution to it?
I'm writing web service to run tests over junit using web endpoint, for this reason I have to keep all tests in sources.
The problem is that I want run tests dirctly from IDEA and command line, and with last I've stucked.
How can I run tests inside sources folder (src/main/java) through "gradle test"?
I'm not fammiliar with gradle, but I've tried to use
sourceSets {
test {
java.srcDir file('src/main/java')
resources.srcDir file('src/main/resources')
}
}
But it breaks project import using IDEA, my 2016.1.1 sometimes can't create two modules with same content root or expectedly marks sources as tests.
Can I solve this problem with customizing test {}, or somehow load test sources into SpringBoot launcher for web service?
Maybe I can extend gradle test task and customize it?
Try removing the file() calls
sourceSets {
test {
java.srcDir 'src/main/java'
resources.srcDir 'src/main/resources'
}
}
Tested on gradle 5.4.1 but should work on other versions too
I guess this post can help you to leanr how to start the tests inside the main sources:
How to run junit tests with gradle?.
I would specify one subfiolder in source which shall contain all your tests.
And you can specify the output directory, which should be different to the default output directory:
sourceSets {
test {
java.srcDir file('src/main/java/tests') // tests shall contain your tests
resources.srcDir file('src/main/resources')
output.resourcesDir = "build/classes/main"
}
}
I have an annotation processor that is automatically picked up by the Java compiler at build time (using SPI). During a gradle build, the generated java sources of this annotation processor are put in build/classes as Gradle tells the annotation processor that this is the place to output generated source files.
When the standard javadoc task is run, it tries to create javadoc for all files in build/classes, including *.java. This failes because javadoc only expects *.class files, making the whole build fail.
So my question is:
Is this a Gradle bug/feature?
How do I fix it/make it work?
It seems the problem is that the generated source files are not picked up, making the javadoc fail because it had nothing to process.
I'm posting the solution here in case somebody is experiencing the same problem:
The problem with compile time source generation in gradle is that the outputted sources are not automatically picked up by the javadoc. This is a problem if all your sources are auto generated. The build will fail with an error saying that no sources could be processed. In the other case your build will succeed but you will have no javadoc of your generated java sources.
The root problem here is gradle's poor integration with generating sources that are both generated and compiled during the same compile step. To remedy this I changed my build files to this.
project layout:
rootproject
rootproject/annotationProcessor
rootproect/userOfAnnotationProcessor
build file of userOfAnnotationProcessor
def generatedSources = "$buildDir/generated-src"
def generatedOutputDir = file("$generatedSources")
compileJava {
doFirst {
generatedOutputDir.exists() || generatedOutputDir.mkdirs()
options.compilerArgs = [
'-s', "${generatedSources}"
]
}
}
sourceSets {
main {
java {
srcDirs += generatedOutputDir
}
}
}
javadoc {
source = sourceSets.main.resources
}
compileJava.dependsOn clean
The trick here is to not add your generated sources to a custom sources set, else we'll run into troubles when trying to build aggregated javadoc in our root project. However this solution has the nasty side effect that our generated sources or added twice for some reason when trying to build after a first clean+build. The solution here is to always do a clean+build.
Now when doing an aggregate javadoc build, we'd like our generated source javadoc to be part of it as well.
This is how our rootproject build file looks like:
def exportedProjects = [
":annotationProcessor",
":userOfAnnotationProcessor",
]
task alljavadoc(type: Javadoc) {
source exportedProjects.collect { project(it).sourceSets.main.allJava }
classpath = files(exportedProjects.collect { project(it).sourceSets.main.compileClasspath })
destinationDir = file("${buildDir}/docs/javadoc")
}
alljavadoc.dependsOn(":userOfAnnotationProcessor:compileJava")
If we had used a custom source set previously, gradle would now start complaining about source set properties not being found. Why? I don't know... A last important thing to notice is that our alljavadoc depeonds on the compilation step of userOfAnnotationProcessor, this is needed to make sure our generated source files are there when the aggregated javadoc is build.
I hope I've helped sombody with this explanation!
I am not quite sure weather it is a bug or not. But as a workaround just filter the sources of javadoc.
Depending on how your build script looks like, it should look something like thistask
myJavadocs(type: Javadoc) {
classpath = sourceSets.main.output.filter { it -> !it.name.endsWith('.java') }
}
Does anyone know how to run the tests from a different gradle project and still get emma coverage reporting data?
Here is my current layout:
Root/
settings.gradle (no explicit build.gradle - just defines all subprojects)
SubProjectA/
build.gradle
src/ (all real source is here)
SubProjectATest/
build.gradle
src/ (all testing code is here)
SubProjectB/ (similar structure as A)
SubProjectBTest/ (similar structure as ATest)
I am currently using the emma plugin, and I would like to build SubProjectA and run all the tests in SubProjectATest from within the build.gradle of SubProjectA.
Here are some things I tried inside the build.gradle of SubProjectA
testCompile project(':SubProjectATest').sourceSets.test.classes (as suggested by this article), but I got an error "Could not find property 'sourceSets' on project"
Just the straight-up testCompile project(':SubProjectATest'), but then I get "..SubProjectA/build/classes/test', not found" and also "Skipping task ':SubProjectA:compileTestJava' as it has no source files."
Simply adding a sourceSet like the following:
test {
java {
srcDir '../SubProjectATest/src'
}
}
Adding the source set in (option 3) is the only option that worked, but it seems sloppy to do it this way. Does anyone know how to do this using project dependencies?
Update #1
I also tried one of the answers below to use test.dependsOn and the tests do run, but the emma plugin reported the following: build/classes/test', not found
1. and 2. just add classes to the test compile class path. This doesn't have any effect on which tests are going to be executed.
3. is the wrong approach because you should not add sources from project X to project Y.
If what you want is that gradle :SubProjectA:test also executes :SubProjectATest:test, all you need to do is to add a task dependency:
SubProjectA/build.gradle:
test.dependsOn(":subProjectATest:test")
By the way, what is your motivation for putting the tests in a separate project?