<Execution> element defines how your tests are executed. Use these settings to run tests in parallel by defining multiple threads, determine how often and when tests are retried, and when to abort the test run due to failing tests passing a specific threshold.
You can also schedule tests to run based on your test history (stored in the SpecRun server). If you use adaptive mode, previously failing tests are prioritised over tests that have passed.
The following attributes are available:
|stopAfterFailures||Optional||The number of failed tests after which the execution of all tests is stopped. Set this to 0 (zero) to execute all tests, irrespective of the number of failures. If not specified, this defaults to 10.
Note: The value in the default
|testSchedulingMode||Optional||Determines the order in which SpecRun executes your tests:
Note: If you set the
|testThreadCount||Optional||The number of tests threads used to execute tests (default=1).
While there is no maximum number of threads, setting this value too high can reduce performance as the individual threads compete for processing power. Setting the number of threads to one less that your number of cores is recommended for
Note: Just increasing the number of threads on its own may cause issues, e.g. if the threads access the same database. It thus makes sense to combine this with a relocation and transformation of the .config file using the
Note: Before and After hooks (e.g. BeforeTestRun, AfterTestRun etc.) are executed per thread.
|retryFor||Optional||Determines which tests should be retried based on their status. Available options:
Note: Tests are retried immediately after returning the corresponding status and before any subsequent tests are executed.
|retryCount||Optional||The number of times tests whose execution status matches the value defined in
|apartmentState||Optional||Sets the apartment state used to execute the tests. Possible values:
Note: Setting the