Develop Reference

Gradle 7.3 with Java 17 with task processIntTestResources: Entry [filename] is a duplicate but no duplicate handling strategy has been set

I am trying to update a gradle 6.x version multi project application to gradle 7.3 as it is the first version to support Java 17. However, I am unable to progress past an issue arising from a task which is not declared in any of my build.gradle files. The error is below: ([] pieces are redacted)
Execution failed for task ':[root module]:[module]:processIntTestResources'.
> Entry [filename] is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/7.3/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details.
I think is associated with a sourceSet for integration tests, however, I never explicitly copy and files for those tests. I have also set all copy instructions to have this configuration with regard to duplicate handling:
duplicatesStrategy = DuplicatesStrategy.INCLUDE
I also tried adding the above to projects which failed because that setting is only valid for Copy type tasks or blocks. I am by no means an expert in gradle and can add any relevant information needed, but I believe I have included what might be most relevant. I am really just looking for a direction I can head in to further debug this issue.

You didn't show much about how you have integration tests configured, but I ran into a similar problem. What saved me was this blog post by Tom Gregory:
Running integration tests in Gradle
Since links can disappear, let me copy and paste the most important part that I found relevant, which is regarding the new (as of Gradle 7.3) JVM Test Suite Plugin that adds support for integration tests. For me, this replaced my old integration test configuration:
testing {
suites {
integrationTest(JvmTestSuite) {
dependencies {
implementation project
}
}
}
}
tasks.named('check') {
dependsOn testing.suites.integrationTest
}
I also found the following useful, which is not in the above blog post, but is a leftover from my previous Gradle 6 configuration. This for me duplicates the 'test' dependencies for 'integrationTest'. This is not the recommended way of handling the test depedencies now (see the JVM Test Suite Plugin documentation), but I still found it useful to get me back running quickly:
configurations {
integrationTestImplementation.extendsFrom testImplementation
integrationTestRuntime.extendsFrom testRuntime
}

How to give System property to my test via Kotlin Gradle and -D

When I run a test in Gradle I would like to pass some properties:
./gradlew test -DmyProperty=someValue
So in my Spock test I will use to retrieve the value:
def value = System.getProperty("myProperty")
Im using the kotlin gradle dsl. When I try and use 'tasks.test' as in this documentation:
https://docs.gradle.org/current/userguide/java_testing.html#test_filtering
'test' is not recognised in my build.gradle.kts file.
I'm assuming I would need to use something similar to the answer in the post below but it is not clear how it should be done in the using the gradle kotlin DSL.
How to give System property to my test via Gradle and -D

The answers from your linked question are translatable 1:1 to the kotlin DSL. Here is a full example using junit5.
dependencies {
// ...
testImplementation("org.junit.jupiter:junit-jupiter:5.4.2")
testImplementation(kotlin("test-junit5"))
}
tasks.withType<Test> {
useJUnitPlatform()
// Project property style - optional property.
// ./gradlew test -Pcassandra.ip=xx.xx.xx.xx
systemProperty("cassandra.ip", project.properties["cassandra.ip"])
// Project property style - enforced property.
// The build will fail if the project property is not defined.
// ./gradlew test -Pcassandra.ip=xx.xx.xx.xx
systemProperty("cassandra.ip", project.property("cassandra.ip"))
// system property style
// ./gradlew test -Dcassandra.ip=xx.xx.xx.xx
systemProperty("cassandra.ip", System.getProperty("cassandra.ip"))
}

This example demos three ways of passing system properties to the junit test. Two of them specifies the system properties one at a time. The last avoids having to forward declare each system property by taking all system properties available to the gradle runtime and passes them to the junit test harness.
tasks.withType<Test> {
useJUnitPlatform()
// set system property using a property specified in gradle
systemProperty("a", project.properties["a"])
// take one property that was specified when starting gradle
systemProperty("a", System.getProperty("a"))
// take all of the system properties specified when starting gradle
// which avoids copying each property over one at a time
systemProperties(System.getProperties().toMap() as Map<String,Object>)
}

How to give test coverage for private constructor of a final class in sonarqube?

I have a util class which is final and I have added one private constructor for hide the default public one. How I can get the coverage for this class in sonarqube with jacoco coverage report and build in Jenkins?
public final class Util {
// My contructor
private Util() {
super();
}
}

According to JaCoCo changelog such private empty no-argument constructors are automatically filtered out starting from JaCoCo version 0.8.0. Changelog also notes:
Tools that directly read exec files and embed JaCoCo for this (such as SonarQube or Jenkins) will provide filtering functionality only after they updated to this version of JaCoCo.
Announcement of release of JaCoCo version 0.8.0 states:
Tools that directly read exec files (which is not a final report) and embed JaCoCo for generation of report will provide filtering functionality only after they updated to this version of JaCoCo.
So please follow/wait/etc respective vendors such as
SonarQube - https://jira.sonarsource.com/browse/SONARJAVA-2608
Eclipse EclEmma - https://bugs.eclipse.org/bugs/show_bug.cgi?id=529391
Jenkins - https://github.com/jenkinsci/jacoco-plugin
Reports generated by corresponding version (0.8.0) of integrations developed as part of JaCoCo project by us (Ant Tasks, Maven Plugin and Command Line Interface) provide filtering functionality.
As of today (30 Jan 2018):
update for SonarQube (https://jira.sonarsource.com/browse/SONARJAVA-2608) is supposed to be in not yet released SonarJava plugin version 5.1
update for Jenkins Plugin (https://github.com/jenkinsci/jacoco-plugin/commit/d04b50962a022b615d5085271f1696d9f6080198) is committed but also not yet released

If you configure sonar to use cobertura (and not jacoco) for the code coverage, you could simply exclude that method from code coverage.
That seems easier than writing an artifical test case using reflection.

How to run single Android local unit test using gradle 2.4. Test filtering is not supported

I'm using gradle to build my android project and am not able to run single local unit test. I have several test classes and one of them is MockServerTest and I only want to run test methods in this class.
I tried using gradle -Dtest.single=MockServerTest test but it turned out running all my tests, including these in other test classes.
I also tried gradle test --tests MockServerTest but an error occurred said
Test filtering is not supported for given version of junit. Please upgrade junit version to at least 4.6.
But I'm using junit 4.12 in my gradle file
testCompile 'junit:junit:4.12'
I'm using gradle 2.4 with com.android.tools.build:gradle:1.2.3.
Also, how can I run a single test method inside a single test class?
BTW, I'm able to run single test method inside Android Studio, by right clicking on the test method and select run targetTestMethod() from the menu. But how can I achieve this in the terminal? I guess Android Studio also trigger a certain command to do this. How can I see what that command is?

Figured it out myself. I have to run
gradle testDebug --tests com.my.package.TestClassName
There are two things to note here.
1. You have to use gradle testDebug or gradle testRelease instead of just gradle test. If you have build variant, you have to use gradle testVariantNameDebug or gradle testVariantNameRelease
2. You have to specify the whole qualified class name, means including the package name.

You can use Android Gradle plugin DSL to set up test tasks filters like this:
android {
testOptions {
unitTests.all {
it.testNameIncludePattern = "*.SomeTest"
}
}
}
You can find more information on testOptions here and filters here.

Have you tried running gradle test -Dtest.single=MockServerTest? More information can be found here.

Integrating Sonar, Jacoco, Gradle, ScalaTest with Junit, Java

I have very successfully integrated Gradle (1.11), Sonar ( 4.1.1 ), Java, Scala and Jacoco in my build process. I even managed to get info regarding the number of successful tests ( thanks to Stackoverflow! ). I have one problem though.
I can't seem to get info about coverage per test. It would be very nice to have this info.
> 15:11:16.514 INFO - Sensor JaCoCoSensor... 15:11:16.535 INFO -
> Analysing C:\example\gradle-sonar-jacoco-scala\build\jacoco\test.exec
> 15:11:17.887 INFO - No information about coverage per test.
A simplified version of the project is at : https://github.com/sebastianharko/gradle-sonar-java-jacoco-scalatest-junit
Cheers !

It Looks like you already have
apply plugin: 'jacoco'
in your gradle.build
But i'm not seeing a definition to where it's to get it file from in the gradle.build
jacoco {
destinationFile = file("$buildDir/jacoco/test.exec")
}
If you plan on doing integration and unit testing it would look similar to the following:
task "integtest"(type: Test, dependsOn: integtestClasses) {
testClassesDir = sourceSets.integtest.output.classesDir
classpath = sourceSets.integtest.runtimeClasspath
jacoco {
destinationFile = file("$buildDir/jacoco/integTest.exec")
}
}
test {
jacoco {
destinationFile = file("$buildDir/jacoco/test.exec")
}
}
With the corresponding sonar configuration items
property "sonar.jacoco.reportPath", "$buildDir/jacoco/test.exec"
property "sonar.jacoco.itReportPath", "$buildDir/jacoco/integTest.exec"

I've seen another conf parameters from SonarQube - integrationTest.exec - sonarRunner (Gradle) or "sonar-runner" command - showing 0.0% covereage :
The parameter sonar.java.coveragePlugin=jacoco called my attention. Did you try that?

You may also want to use Coveralls.io
It's very cheap: only $4.99/mo. and you would have a deep integration with your pull requests on Github (track when a branch increases or decreases your code coverage) as well as a very nice UI to drill down into your code coverage.
Both SBT and Gradle integrations are available.