Using Gradle and its JUnit 4 support, I can choose a specific test using the --tests option like this:
$ ./gradlew test --tests de.mp.BarMT
This option is ineffective when using the JUnit 5 Gradle task. It is ignored silently when using the test tasks from the command line. The true work is done by junitPlatformTest anyway, and it does not support the option:
$ ./gradlew clean junitPlatformTest --tests de.mp.BarMT
…
Problem configuring task :junitPlatformTest from command line.
> Unknown command-line option '--tests'.
Does the JUnit 5 plugin support choosing specific tests?
Answering myself… A lot of time has passed, new versions came, and I can confirm that with Gradle 5.4.1 and JUnit Jupiter Platform 1.4.2, the simple configuration:
test {
useJUnitPlatform()
}
will allow running single tests as seen in https://stackoverflow.com/a/31468902/2621917, even when using weird names (from Kotlin):
gradle test --tests 'HtmlForwardInterceptorTest.should forward requests'
Related
I have made a project from where I intent to run integration tests using docker: https://github.com/navikt/bidrag-cucumber-nais
In this project, I have
a kotlin application called IntegrationTests.kt
a pom.xml which makes maven build the application
I would like to
only run cucumber tests from the application: IntegrationTests.kt
only run unit tests from maven
Issues I do not understand:
from IntelliJ: when running junit tests, it will run cucumber and "regular" junit tests (this is expected behaviour)
from IntelliJ: when running the application, IntegrationTests.kt, cucumber tests are run (this is expected behaviour)
from maven: I have two profiles which eirher run junit-jupiter (by default) or junit-vintage (cucumber tests from cli). The profile running junit-vintage will not discover any tests... (?)
from console: I cannot run the executable jar which are build... (?)
from IntelliJ: when running junit tests, it will run cucumber and "regular" junit tests
IDEA has runners for both JUnit 4 and JUnit 5. They're enabled when you have either one on the class path.
from maven: only junit tests with cucumber is run (junit vs junit-jupiter?)
Maven only enables one runner at a time, either JUnit 4 or JUnit 5 and defaults to the more modern version when multiple are present. You are using cucumber-junit which is a JUnit 4 integration. Consider adding junit-vintage in addition to junit-jupiter. That way JUnit 5 can run JUnit 4 tests or consider using junit-platform-engine.
Hey guys I am having a little trouble with the gradle wrapper.
Is there any good way to compile all my code, compile all my tests, and run a single test.
This is for a scripting command in a Jenkins pipeline.
I have used
./gradlew build, which runs all the tests
./gradlew build -x test, which compiles all main code and not allow me to run any tests
Thanks for any help
see the gradle documentation https://docs.gradle.org/current/userguide/java_testing.html#test_filtering
# Executes all tests in SomeTestClass
gradle test --tests SomeTestClass
# Executes a single specified test in SomeTestClass
gradle test --tests SomeTestClass.someSpecificMethod
gradle test --tests SomeTestClass.*someMethod*
# specific class
gradle test --tests org.gradle.SomeTestClass
# specific class and method
gradle test --tests org.gradle.SomeTestClass.someSpecificMethod
I've 2 CI flows , which flow needs to run it's own cucumber runner
RunnerATest
RunnerBTest
I'm using maven command line to run the tests (mvn test)
Is there a way to select a specific Runner from command line ?
Thanks
Maven Surefire Plugin - Running a Single Test
During development, you may run a single test class repeatedly. To run this through Maven, set the test property to a specific test case.
mvn -Dtest=TestCircle test
So you'd do just that. mvn -Dtest=RunnerATest test.
my question is can i run by gradle a few needed for me spock tests?
I mean not packages and classes, only tests. I know the way how i can run one test:
./gradlew testTask --tests "*TestName*"
TestTask contains only include package where tests was placed.
I tried code like this:
./gradlew testTask --tests "*TestName*","*TestName2*"
It Doesn't work.Maybe someone know how i can do this?
According to the docs --tests is an option that you can repeat. So, you should be able to specifically pick multiple tests to run with:
./gradlew testTask --tests "*TestName*" --tests "*TestName2*"
For Gradle 3.x you can apply only one filtering rule to a single --tests switch. In your case I see two possible solutions:
You can create a wildcard that will satisfy tests you expect to run (and only them), e.g.
./gradlew testTask --tests "*TestName*"
this rule will satisfy both, TestName.java and TestName2.java
You can create separate test tasks and apply different filtering rule to them, e.g.:
./gradlew firstTestTask --tests "*TestName*" secondTestTask --tests "*TestName2*"
It is verbose, but you have a control over all filtering rules.
Please take a look to Gradle's documentation for more information: https://docs.gradle.org/3.3/userguide/java_plugin.html#test_filtering
Using Android studio with gradle wrapper version 2.2.1, I am trying to run all the tests in one single test class, as well as a specific test inside that class and have tried using:
./gradlew test --tests DownloadsActivityTest
like the documentation suggests, as well as
-DandroidTest.single=DownloadsActivityTest
But neither of these versions work.
How do I run a single test class, and a single test from the command line using the gradle wrapper?
./gradlew --version
------------------------------------------------------------
Gradle 2.2.1
------------------------------------------------------------
Build time: 2014-11-24 09:45:35 UTC
Build number: none
Revision: 6fcb59c06f43a4e6b1bcb401f7686a8601a1fb4a
Groovy: 2.3.6
Ant: Apache Ant(TM) version 1.9.3 compiled on December 23 2013
JVM: 1.7.0_51 (Oracle Corporation 24.51-b03)
OS: Linux 3.17.6-200.fc20.x86_64 amd64
[16:33][j#localhost:~/myHomeDir]$ ./gradlew test --tests DownloadsActivityTest
WARNING: Dependency commons-logging:commons-logging:1.1.1 is ignored for debugTest as it may be conflicting with the internal version provided by Android.
In case of problem, please repackage it with jarjar to change the class packages
WARNING: Dependency org.apache.httpcomponents:httpclient:4.0.3 is ignored for debugTest as it may be conflicting with the internal version provided by Android.
In case of problem, please repackage it with jarjar to change the class packages
FAILURE: Build failed with an exception.
* What went wrong:
Problem configuring task :app:test from command line.
> Unknown command-line option '--tests'.
* Try:
Run gradlew help --task :app:test to get task usage details. Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: 4.466 secs
To only run instrumentation tests (androidTests) in a specific test class, execute:
./gradlew app:connectedAndroidTest -Pandroid.testInstrumentationRunnerArguments.class=com.example.android.testing.blueprint.ui.espresso.EspressoTest
To only run local tests ("unit", JVM tests) in a specific test class or package execute:
./gradlew :app:testDebugUnitTest --tests "com.example.android.testing.blueprint.unit.integrationTests.*"
./gradlew :<module name>:test<CapitalCasedBuildVariant> --tests "<Test name pattern>"
It is important to specify the module name where the test lives, otherwise, when gradle builds dependent modules, it will attempt to test them, and might fail because none of the tests fit the test pattern:
No tests found for given includes: [FooTest]
Also, unless you specify the fully-qualified-name (FQN) of the test, your test name pattern should start with a *.
In my case, I have a module named app and a variant named localDebug, and I wanted to test FooTest, so I ran:
./gradlew :app:testLocalDebug --tests "*FooTest"
This is supported in Android Studio 1.1, using the Android Gradle plugin v1.1.0.
Follow the guide here
The Android Gradle plugin, as of 1.0.0, doesn't have support for running single Android tests. The feature request for it is filed at https://code.google.com/p/android/issues/detail?id=74196.
I know that better test support in general is very high on the post-1.0 priority list, but I can't say with any certainty when this will be implemented.