https://gradle.com/ logo
Join Slack
Powered by
I'm trying out the new <JvmTestSuite> plugin but c...
# community-support
b
I'm trying out the new JvmTestSuite plugin but can't get junit tags to work
Copy code
testing {
    suites {
        val test = named<JvmTestSuite>("test") {
            useJUnitJupiter()
        }
        register<JvmTestSuite>("integration") {
            dependencies {
                implementation(project())
            }
            targets {
                all {
                    testTask.configure {
                        useJUnitPlatform {
                            includeTags("integration")
                        }
                        shouldRunAfter(test)
                    }
                }
            }
        }
    }
}
Copy code
import org.junit.jupiter.api.Assertions.*
import org.junit.jupiter.api.Tag
import org.junit.jupiter.api.Test
@Tag("integration")
class ProductControllerTest {
    @Test
    fun name() {
        assertEquals(1, 21)
    }
}
there are also no examples on how to configure junit. ./gradlew test executes the failing test, ./gradlew integration doesn't
✅ 1
v
You have that test class twice, right? If you only have it in 
src/test/java
, then - well - you only have it in 
test
, not 
integration
unless you configure the 
integration
suite to use the same sources which would be strange and time-wasting as you then also compile twice.
b
does it need to go into a separate folder?
v
You probably wanted to add a target to the 
test
suite in that case
does it need to go into a separate folder?
Like you configured it, yes
b
I see, thanks
v
Separate test suite by default uses separate source set, so 
src/integration/java
b
in that case I don't think I need junit tags
v
Exactly. If you want tags, you probably want to use something like
Copy code
testing {
    suites {
        named<JvmTestSuite>("test") {
            useJUnitJupiter()
            targets.register("integration") {
                testTask.configure {
                    useJUnitPlatform {
                        includeTags("integration")
                    }
                }
            }
        }
    }
}
But usually I prefer to have different test types in different source sets
b
when renaming the directory though it looks like I don't have access to testImplementation dependencies of the project
v
Tags I use for other things, for example if you have snapshot tests and mark all those with a tag, then you can start a special run that updates all snapshots and only executes those relevant tests and not the others.
when renaming the directory though it looks like I don't have access to testImplementation dependencies of the project
Of course not
They are dependencies for the 
test
source set, not the 
integration
source set
b
I see, is there an easy way to pull those in?
v
If you want all 
integration
have the same dependencies as 
test
, you make the relevant 
integration...
configurations extend from the according 
test...
configurations
Or you just declare the dependencies for each
Often integration tests need different dependencies anyway
For example unit tests, test the classes and methods, and integration tests start up a CDI container and do CDI integration tests and so on.
Most often totally different dependencies needed and only some common
b
in my case it's a spring boot project, so pretty similar overall
v
Well, however you prefer. 🙂
b
how do I extend tasks?
v
Not tasks, configurations
Copy code
configurations.named("integrationImplementation") {
    extendsFrom(configurations.testImplementation)
}
configurations.named("integrationApi") {
    extendsFrom(configurations.testApi)
}
configurations.named("integrationCompileOnly") {
    extendsFrom(configurations.testCompileOnly)
}
...
Btw. don't use the Spring Dependency Management Gradle plugin. It is a relict from times when Gradle did not have built-in BOM support, by now does more harm than good, and even its maintainer recommends not to use it anymore, but the built-in BOM support using 
platform(...)
.
b
ah, thanks; they still include it in newly generated projects from start.spring.io though
v
Yes, and that is simply wrong. The also have it first in the docs and if you scroll down, then the proper way. Complain to them, I'm not a Spring Boot user
And if, then I write my build myself 🙂
b
thank so you much, pretty tricky to make do with the existing docs on that; and they silently broke my previous junit test suits, just found out today
👌 1
3 Views
Open in Slack
PreviousNext
Powered by