splitTests: Split Test Runs

• parallelism
  Nested Choice of Objects
  • count
    Always divide the tests into N parallel sub-tasks of about equal size. This mode is useful if your build slaves are not elastic to control the resource consumption by this task.

    • size : int
  • time
    Divide the tests into parallel sub-tasks each no bigger than N minutes. Combined with elastic slaves, such as EC2, the turn-around time of the tests will remain the same no matter how many tests you add.

    This value counts just the time spent on executing tests, and not including other time such as checking out the code, building the test, etc. For example, if your test job spends 50 minutes in tests and 60 minutes total from start to finish, then you have 10 minutes "fixed" overhead regardless of the number of tests it executes. If you use this mode and set the value to "10 minutes", then you'll have 5 parallel sub-tasks that all ends in roughly 20 minutes (20 mins = 10 mins tests time + 10 mins overhead.)

    "N minutes per a sub-task" is a goal, not a hard constraint. So a sub-task can take longer (for example if you have a single test that takes more than N minutes.)

    • mins : int
• estimateTestsFromFiles : boolean (optional)
• generateInclusions : boolean (optional)

  If disabled, the splitStep call will return a List<List<String>> containing the exclusion patterns for the different buckets.

  If enabled, the splitStep call won't return a List<List<String>>.
  Instead it will return a List of a structure with :

  • boolean includes whether the following list is an inclusion or an exclusion list
  • List<String> list the list of patterns

• stage : String (optional)
  If defined, only consider tests recorded in the previous build in the named stage.
• testMode (optional)

  Configure how exclusions and inclusions are formed from the JUnit result XML. The test job receiving the exclusion/inclusion files must be able to handle the format produced by the selected mode.

  Nested Choice of Objects
  • javaClass
    This mode works best with java projects.

    Each exclusion/inclusion generates two lines by replacing "." with "/" in the fully qualified test class name and appending ".java" to one line and ".class" to the second line.
  • javaParamTestCase
    This mode works best with Java projects.

    Parallelize per Java test case including parameters.

    It is also able to estimate tests (per class) to run from the workspace content if no historical context could be found.
  • javaTestCase
    This mode works best with Java projects.

    Parallelize per Java test case ignoring parameters. If parameters are present they are considered the same test.

    It is also able to estimate tests (per class) to run from the workspace content if no historical context could be found.
  • testCase
    Each exclusion/inclusion generates one line consisting of the test case name only.

    This is useful where a tool produces JUnit result XML containing unique test case names without any class prefix.
  • qualifiedTestCase
    If checked, each exclusion/inclusion generates one line consisting of the class and test case name on a className.testName format.