Show Test Run Results - Nextedy Documentation

Verify column IDs, field names, and Velocity APIs against your installation before promoting the configuration to production.

When to Use This

This pattern is useful whenever a row in Risksheet represents an item that is verified by a Polarion Test Case, and you want each row to surface the most recent test execution result for that item. Typical scenarios:

A requirements + test cases sheet where each requirement row shows the latest pass/fail of its linked test case.
A safety-controls sheet (ISO 26262, IEC 61508) where each control row must display the latest verification status.
A V&V traceability matrix that needs an at-a-glance “last result” column for audit purposes.

Prerequisites

Before you start, confirm the following:

Risksheet is embedded in a Polarion LiveDoc and you can edit its sheet configuration.
Rows in the Risksheet are linked to Test Cases (either directly as the row work item type, or via a link role such as verifies).
At least one Test Run exists in the project and has been executed against the relevant Test Cases.
You have permission to edit the sheet configuration and (optionally) the top panel template.

Open the Sheet Configuration

Open the Risksheet document in Polarion.
From the document menu, choose Menu > Configuration > Edit Risksheet Configuration.
The YAML editor opens with the current sheet configuration.

If you need help locating the configuration, see Find Configuration Files.

Add a Server-Rendered Column

The Test Run column is rendered on the server because it needs to call the Polarion test management API for each row. Add a new column to the columns section:

columns:
  - id: lastTestResult
    header: Last Test Run
    bindings: task.$item
    width: 220
    serverRender: lastTestRecord
    readOnly: true

Key points:

bindings: task.$item — gives the Velocity template access to the entire linked Test Case work item (not just one field). Use this binding pattern whenever a server-rendered column needs to traverse fields or call services on the linked item.
serverRender: lastTestRecord — references a Velocity macro you will define in the next step. The macro name is arbitrary; pick something descriptive.
readOnly: true — server-rendered cells cannot be edited, so the flag is implicit, but stating it makes intent clear in audits.

The property is bindings (plural). A common mistake when hand-editing the configuration is to write binding (singular) — the engine will silently ignore the column. Double-check this if your column renders as blank.

If the rows in your sheet are Test Cases themselves (not items that link to Test Cases), use bindings: $item instead and adjust the Velocity macro to operate directly on $item.

Define the Velocity Macro

The server-rendered column references a Velocity template. By convention, server-render templates live in the top panel configuration (risksheetTopPanel.vm) so they can be reused across columns.Open the top panel template (Menu > Configuration > Edit Top Panel) and add the following macro:

#macro(lastTestRecord $item)
  #set($records = $testManagementService.getLastTestRecords($item.getOldApi(), 1))
  #if($records && $records.size() > 0)
    #foreach($r in $records)
      #set($runId = $r.getTestRun().getId())
      #set($result = $r.getResult().name())
      <span title="$runId">$runId — $result</span>
    #end
  #else
    <span style="color:#999;">No execution</span>
  #end
#end
#lastTestRecord($item)

What the macro does:

Calls $testManagementService.getLastTestRecords($item.getOldApi(), 1) to fetch the most recent test record for the linked Test Case.
Reads the Test Run ID with getTestRun().getId() and the result enum with getResult().name().
Renders the Test Run ID and the result (e.g. passed, failed, blocked) as a single cell.
Shows a muted placeholder when the Test Case has never been executed.

$testManagementService is part of Polarion’s Velocity context. If the variable is not available in your installation, ask your administrator to confirm it is exposed in the Risksheet top panel scope. The API surface (getLastTestRecords, getResult) follows Polarion’s test management service.

Save and Refresh

Save the sheet configuration (the YAML editor validates the syntax on save).
Save the top panel template if you edited it in step 3.
Reload the Risksheet document in the browser.

The new Last Test Run column appears at the position you placed it. Each row that has a linked Test Case with at least one execution shows the Test Run ID and the result. Rows with no execution show the “No execution” placeholder.

Add Conditional Styling (Optional)

To make pass/fail status obvious, colour the cell based on the result. In the sheet configuration:

styles:
  '.test-passed': '{background-color: #eaf5e9 !important;}'
  '.test-failed': '{background-color: #ffebee !important; font-weight: 600;}'
  '.test-blocked': '{background-color: #fff8e1 !important;}'

cellDecorators:
  lastTestResultDecorator: |
    function(info){
      var v = (''+info.value).toLowerCase();
      $(info.cell).toggleClass('test-passed', v.indexOf('passed') >= 0);
      $(info.cell).toggleClass('test-failed', v.indexOf('failed') >= 0);
      $(info.cell).toggleClass('test-blocked', v.indexOf('blocked') >= 0);
    }

Then attach the decorator to the column:

columns:
  - id: lastTestResult
    header: Last Test Run
    bindings: task.$item
    serverRender: lastTestRecord
    cellRenderer: lastTestResultDecorator
    readOnly: true

Result keyword	Style class	Visual cue
`passed`	`.test-passed`	Light-green background
`failed`	`.test-failed`	Light-red, bold text
`blocked`	`.test-blocked`	Light-amber background
anything else	— none —	Default cell appearance

Cells are reused as the grid scrolls. Setting inline styles such as info.cell.style.backgroundColor = 'red' causes “ghost” colours to appear on unrelated rows. Always apply styling with $(info.cell).toggleClass(...) so it follows the cell when it is reassigned.

Add the Column to Saved Views (Optional)

If your sheet uses saved views, add the new column to the relevant ones so reviewers see it by default:

views:
  - name: Verification Status
    defaultView: true
    columnIds:
      - "@all"
      - "-internalNotes"
  - name: Failures Only
    columnIds:
      - id
      - title
      - lastTestResult

See Create Saved Views for the full views syntax, including the @all shorthand and the -columnId exclude prefix.

Common Pitfalls

Most common causes:

Wrong binding name. The property must be bindings (plural). A singular binding is ignored.
The macro name in serverRender does not match the #macro(...) definition. Names are case-sensitive.
The row is not linked to a Test Case. Server-render is called once per row; if the linked item is missing, $item is null and the macro silently produces no output.

Server-rendered columns are evaluated once per row, but the macro must read its data from $item — not from a hard-coded ID or a top-level variable. Double-check that getLastTestRecords($item.getOldApi(), 1) uses $item, not a global like $document.

Each row makes a server call to fetch the latest record. On sheets with hundreds of rows, the initial load is noticeably slower. Mitigations: limit the column to the saved view(s) where it is needed; combine multiple test-related fields into a single server-rendered column to amortise the call.

Verification

You should now see, for every Risksheet row that links to a Test Case:

A Last Test Run cell containing the Test Run ID and the result (for example TR-014 — passed).
Background colour matching the result (green for passed, red for failed, amber for blocked) if you applied the optional decorator from step 5.
“No execution” in muted grey for Test Cases that have not yet been executed.

To confirm the column is wired to live data, execute a Test Case from a Test Run and reload the Risksheet — the cell should update to reflect the new result.

​When to Use This

​Prerequisites

​Common Pitfalls

​Verification

​See Also

When to Use This

Prerequisites

Common Pitfalls

Verification

See Also