Run

Set some preferences used running the cases:

timeout:
Sets the maximum number of seconds allowed to run a case. (to avoid that a wrong case expends infinite time)

max process:
Sets the maximum number of simultaneous exes to be run from the tester.
Running a lot of big cases simultaneously could be unaffordable for the system (the RAM and CPU are a limited resource)

Run filters:
Filters are a mechanism to hide some cases (and not to run them)

• filter date: To hide and not to run the cases that were already run by the exe, based on the date of the exe and the date of the last valid test.

If a new exe is compiled its date is more recent and then all tests are done in order to check that this version is not corrupted.

• filter time: To hide expensive (run time) cases, and do light tests running only cases faster that the specified minutes

(the time of a test is based on previous run, if a case was never run then its expected time is unknown)

• filter memory: To hide expensive (memory) cases, and do light tests running only cases that spend less that the specified MB of RAM

(the RAM use of a test is based on previous run, if a case was never run then its expected memory requirement is unknown)

• filter tags: Allows to hide cases that no contain in its 'tags' property any of the 'active selected tags'.

A case has as 'tags' an ordered list of words, used to classify the cases as a tree (in case of select this kind of view)
e.g.
Imagine that we have some expensive cases in a 'tree path' defined by its case tag: thesis barcelona

to avoid running them we must deactivate the words 'thesis' and 'barcelona' in the filter tags window:

and the cases will be hidden

• filter fail: To hide the cases that have failed (fail=1) the last test or the tests that are ok (fail=0) the last test.

(if a case was never run then its result is unknown)

• filter fail accepted: a case could be marked in its properties as 'fail accepted', this mean that we 'a priori' know that the case will fail (maybe until some difficult error will be fixed)

and we don't want to run this test, but we also don't want to delete it from the database of cases. Enabling this filter these cases will be hidden.
When the problems of the program will be fixed the case must be declared again as 'affordable' to be considered.

• filter platform provide: Some cases are known 'a priori' that could be run only in a platform, in this case they must declare it with 'platform require' in its properties.

Enabling this filter these cases with 'platform require' unsupported by the 'platform provide' statement will be hidden.

• filter branch provide: Some cases are known 'a priori' that could be run only by a branch line (e.g. only the developer version), in this case they must declare it with 'branch require' in its properties. Enabling this filter these cases with 'branch require' unsupported by the 'branch provide' statement will be hidden.