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.
Related
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
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`
Is there any way to specify the order of the unit tests classes run by a Gradle Test task?
I'd like to get some known longer-running tests at either the front or the back of the list, but don't know if it's possible without splitting my tests' execution between multiple tasks.
Running JUnit 4.12 and Gradle 4.5.
Gradle simply delegates execution to the JUnit runner.
So if you want specific test class ordering, you will need to create a Suite and specify the test classes in the order you want, see the JUnit documentation for this.
Now, given the flexibility of Gradle in terms of having different source roots, I would strongly recommend doing the separation at the Gradle level, by create extra test source roots, test task and the like. This will allow you to effectively control when these long running tests are run in a standard build execution, but also to skip them or run these only when desired. The ordering at the JUnit level will not give that flexibility without much more tweaking. See the Gradle documentation on adding source sets.
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.
Gradle java plugin offers a classes task, which describes
"Assembles the production classes and resources directories."
what does it mean? what exactly it does.
One more task is check, it says
All verification tasks in the project, including test.
what does this means? what are the other verification tasks apart from test?
Assembles the production classes and resources directories
It assembles under your build directory both class-files and resources, in the classes and resources folders accordingly. It depend on the comlipe and processResources tasks and make both of them run. That mean, that you can get the content, in your build folder, which later will be added into some archive (jar, war or ear) if you'll call some task to assemble it.
what are the other verification tasks apart from test?
You can add some plugins to your build script, for example checkstyle or findbugs. This plugins add some additional verifications, such a static analysis of source code and etc. All this actions will be performed while check is executed.