anchor.diff:  [cols="a,a,a", options="header"]
   |===
   | Directory
  -| 
  +|
   | Meaning
   
   include::javaProjectMainLayout.adoc[]
  
positive.code: * `gradle test --tests \*SomeSpecificTestSuite`
  * `gradle test --tests all.in.specific.package\*`
  * `gradle test --tests \*IntegTest`
  * `gradle test --tests \*IntegTest\*ui\*`
  * `gradle test --tests "com.example.MyTestSuite"`
  * `gradle test --tests "com.example.ParameterizedTest"`
  * `gradle test --tests "\*ParameterizedTest.foo\*"`
  * `gradle test --tests "\*ParameterizedTest.\*[2]"`
  * `gradle someTestTask --tests \*UiTest someOtherTestTask --tests \*WebTest\*ui`
   
  
  [[sec:single_test_execution_via_system_properties]]
  ==== Single test execution via System Properties
  
negative.code: [[test_filtering]]
  ==== Test filtering
  
  Starting with Gradle 1.10, it is possible to include only specific tests, based on the test name pattern. Filtering is a different mechanism than test class inclusion / exclusion that will be described in the next few paragraphs (`-Dtest.single`, `test.include` and friends). The latter is based on files, e.g. the physical location of the test implementation class. File-level test selection does not support many interesting scenarios that are possible with test-level filtering. Some of them Gradle handles now and some will be satisfied in future releases:
  
  * Filtering at the level of specific test methods; executing a single test method
  * Filtering based on custom annotations (future)
  * Filtering based on test hierarchy; executing all tests that extend a certain base class (future)
  * Filtering based on some custom runtime rule, e.g. particular value of a system property or some static state (future)
  
  
  Test filtering feature has following characteristic:
  
  * Fully qualified class name or fully qualified method name is supported, e.g. “org.gradle.SomeTest”, “org.gradle.SomeTest.someMethod”
  * Wildcard '*' is supported for matching any characters
  * Command line option “--tests” is provided to conveniently set the test filter. Especially useful for the classic 'single test method execution' use case. When the command line option is used, the inclusion filters declared in the build script are ignored. It is possible to supply multiple “--tests” options and tests matching any of those patterns will be included.
  * Gradle tries to filter the tests given the limitations of the test framework API. Some advanced, synthetic tests may not be fully compatible with filtering. However, the vast majority of tests and use cases should be handled neatly.
  * Test filtering supersedes the file-based test selection. The latter may be completely replaced in future. We will grow the test filtering API and add more kinds of filters.
  
  
  
  ++++
  <sample xmlns:xi="http://www.w3.org/2001/XInclude" id="testfiltering" dir="testing/filtering" title="Filtering tests in the build script">
                      <sourcefile file="build.gradle" snippet="test-filtering"/>
                  </sample>
  ++++
  
  For more details and examples please see the api:org.gradle.api.tasks.testing.TestFilter[] reference.
  
  Some examples of using the command line option:
  
  * `gradle test --tests org.gradle.SomeTest.someSpecificFeature`
  * `gradle test --tests \*SomeTest.someSpecificFeature`
  