Regular Expression Test Post-Processor
The Regular expression test post-processor is used to process arbitrary unstructured test reports. Based on a single regular expression, the test report is processed one line at a time. Test name and status information is extracted from each line and used to generate a test report.
 | Escaping
Note that as the dollar sign character ($) and backslash character (\) have special meanings both in Pulse files and in regular expressions, you must take care when writing expressions that include these characters. See Escaping in Regular Expressions for details. |
Attibutes
| Attribute |
Description |
Required? |
Default |
| name |
The name of the post-processor. |
Yes |
|
| details-group |
The index of the regex group that contains test details (reported in the details column in test reports). |
No |
|
| fail-on-failure |
Indicates whether or not the build should be marked as failed if a test fails |
No |
True |
| failure-status |
The test status that indicates the test has failed. |
No |
FAILURE |
| name-group |
The index of the regex group that contains the test name. |
Yes |
|
| pass-status |
The test status that indicates the test has passed. |
No |
PASS |
| regex |
The regular expression used to extract information. |
No |
|
| resolve-conflicts |
Allows customisation of the behaviour when two tests cases that have identical names are found. The default is "off", in which case duplicate cases are collapsed into a single case. Other valid values are "append" and "prepend", both of which force case names to be unique by adding a number (to the end or beginning of the case name respectively). |
No |
off |
| status-group |
The index of the regex group that contains the test status. |
Yes |
|
| trim |
Indicates whether or not whitespace should be trimmed from around the regex. |
No |
True |
| suite |
If a suite is specified, all tests found by this processor will be added to that suite. |
No |
|
Note: If the regex is not defined as an attribute, it must be defined in the body of the post processor. See below for an example.
Child Elements
None.
Examples
In this example, we want to configure the regex-test post processor to handle the following test report
[PASS] 10/16/2006:18:20:58:EDT: <TEST COMMAND>
[PASS] 10/16/2006:18:20:58:EDT: <TEST COMMAND>
[PASS] 10/16/2006:18:20:58:EDT: <TEST COMMAND>
[FAIL] 10/16/2006:18:20:58:EDT: <TEST COMMAND>
[PASS] 10/16/2006:18:20:58:EDT: <TEST COMMAND>
[PASS] 10/16/2006:18:20:58:EDT: <TEST COMMAND>
In this test report, we see that the status of the test is available at the start of the line, indicated by PASS or FAIL, and the name of the test is available at the end of the line, ie: TEST COMMAND. A simple regex that can extract this information would be [(.*)].*<(.*)>, where regex group 1 is the status and group 2 is the test name. Using this information, we can configure the test-regex post processor as follows:
<regex-test.pp name="sample-regex-test" status-group="1" name-group="2" pass-status="PASS" failure-status="FAIL"><![CDATA[\\[(.*)\\].*<(.*)>]]></regex-test.pp>
<recipe name="default">
<command name="build">
<ant targets="build.all"/>
<artifact name="test report" file="build/reports/test.txt" fail-if-not-present="false">
<process processor="${sample-regex-test}"/>
</artifact>
</command>
</recipe>
Note that in this example, because the regular expression contains '<' and '>', it needs to be specified in a CDATA section. If the '<' and '>' characters were not there, then the regex can be specified as an attribute.