Our project recently started separating our unit and integration tests, which used to all be contained within the same package. We created a task to kick off our integration tests:
task intTest(type: test){
systemProperty ..., System.properties[...]
systemProperty ..., System.properties[...]
include '**/*Int*.java','**/*.func*.java','my.path.to.api.files.*'
}
However I"ve noticed that none of our Integration nor Functional tests are running. From what I can see our pattern looks correct. Any ideas as to why they're not being kicked off?
I am running from CLI using gradle :application:intTest
This works correctly. We had a dependency issue which was breaking us.
My app.gradle file was inheriting from a common.gradle file. The common.gradle file had the same name for one of the tasks, which was breaking the tests. I changed the name and it works perfectly now.
Related
I've found this code at work in build.gradle
configurations {
all {
resolutionStrategy {
cacheDynamicVersionsFor 0, 'seconds'
}
}
integration
}
I can't find anywhere what integration keyword stands for. Can you explain to me?
In this example, the build is declaring a new configuration called integration. And a configuration can for the most part be thought of as a bucket or collection of dependencies. If a plugin or the Gradle core new about a particular configuration, there would usually be no need to declare it as it would already exist to begin with.
Let's assume that 'integration' is short for 'integration test'. Then what's going on here is that your build is saying: "Hey, I need a bunch of dependencies for running my integration test, but I don't want to pollute the classpath for the other kinds of runtime environments. So please make me a bucket of dependencies to isolate the integration test".
Later in the build file (which you didn't show), you will then find a dependencies block where the integration configuration is populated with the modules needed for running the test. And lastly, some task that actually uses it, presumably for setting the classpath.
It could be used for a number of other things of cause. But whatever it is, it is probably something custom and you could rename it (and all references to it) to 'aCollectionOfAwesomeDependenciesUsedForRunningOurIntegrationTest' if you like.
I'm creating a fairly large test suite using gradle, geb, and spock in conjunction. Gradle is obviously building and kicking off geb and spock, but I think that spock is where I can control and specify which Spec to run.
I'm building this based off of this starter.
https://github.com/AutomationSchool/geb-and-spock-automation-examples
How can I set this to run just one Spec?
Gradle's Test task takes a tests option. The supported patterns are documented in the javadoc for TestFilter. So if you want to run spec class called MySpecToRun in the project you linked to then you can do it this way:
./gradlew chromeTest --tests=MySpecToRun
If I have:
build.gradle
System.out.println("${tasks.bootJar.mainClassName}")
Main class name has not been configured and it could not be resolved
So I comment out System.out.println, run the build again. Success.
Now if I uncomment out my System.out.println the main class name properly prints until I do a gradle clean.
Clearly some predicate job is running and being cached and that result is necessary for the println to work. Can anyone tell me how I can figure out which task it is and how to force it first?
I still don't understand how to properly troubleshoot this (ie a good reference on debugging task ordering and such). In my particular instance, browsing around on Github I found a more specific property which seems to always be available for mainClassName
tasks.bootJar.properties.mainClassName
I found this page that explains how to run Geb/Spock tests at the method level which is what I would like to do with my tests, but I am using gradle. Is there a way to convert this to gradle or is it strictly a maven plugin? I can import the maven-surefire-plugin with gradle just fine, however I can't figure out how to convert the configuration block, or if it is even possible.
I've tried something like below but it doesn't work.
tests {
options {
parallel = "methods"
forkCount = 4
}
}
I can execute the tests at the class (spec) level by using gradle maxParallelForks property, but I'd like to run parallel at the test level.
If you are able to run tests in parallel on the method level depends on what test framework you are using.
As far as I know, only TestNG supports it out of the box.
See here: https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/testing/testng/TestNGOptions.html#setParallel-java.lang.String-
There is way to make it work independently of the test framework, using only Gradle, but this way you can only do it on the class level.
In your Gradle test task, set the maxParallelForks property.
See manual: https://docs.gradle.org/current/dsl/org.gradle.api.tasks.testing.Test.html#org.gradle.api.tasks.testing.Test:maxParallelForks`
There is more and more gradle code in my build.gradle.
The question is how to test gradle code from build.gradle. Is there any convention?
I'm not sure if this is convention but what You need to do is to make use of gradle tooling API. Basically it enables to You to load a build.gradle file, execute various tasks and verify the output. This code may be written as a normal test classes. You can find examples of such testing here and here for instance. Tests are written in spock.
Usually, code in build.gradle isn't tested. Instead, reusable/generic parts of the code are factored out into plugins and tasks implemented as classes, which are more amenable to testing.
A potential alternative is to test a task A by adding a task testA that depends on A and checks the outcome of A.