---
title: Testing Trust Framework elements
description: Test Trust Framework elements from end-to-end with tools that show the complete processing flow.
component: pingauthorize
version: 11.0
page_id: pingauthorize:pingauthorize_policy_administration_guide:paz_trust_framework_testing
canonical_url: https://docs.pingidentity.com/pingauthorize/11.0/pingauthorize_policy_administration_guide/paz_trust_framework_testing.html
revdate: December 9, 2024
section_ids:
  about-this-task: About this task
  steps: Steps
  example: Example:
  result: Result:
  testing-repeating-attributes: Testing repeating attributes
---

# Testing Trust Framework elements

Test Trust Framework elements from end-to-end with tools that show the complete processing flow.

## About this task

Testing enables you to validate the type conversion of policy information points (PIP) included in decision requests and the logical behavior of conditions.

Although [policy testing](paz_policy_testing.html) indirectly tests your Trust Framework elements, testing each Trust Framework element individually allows you to immediately view the output of element processing without parsing policy test results.

Use Trust Framework testing to:

* Verify attribute or service [value settings](paz_value_settings.html).

  If you are testing an attribute with a value type other than `String`, the decision engine must convert this attribute from a string provided in the request to the correct type. Testing an attribute or service allows you to verify that the formatting required for this conversion is correct.

* Test the behavior of [processors](paz_value_processing.html).

  The decision engine's conversion of request parameters from string to other data types, such as `Number`, might involve a chain of processors configured in the attribute definition. Testing an attribute allows you to determine before runtime whether such processing produces the desired outcome.

* Test the behavior of [resolvers](paz_resolvers.html).

  If you define multiple resolvers on an attribute, you can use testing to confirm the order in which the decision service checks these resolvers for a value.

* Test the logic of [conditions](paz_conditions.html).

  With testing, you can confirm that your conditional logic produces the desired outcome before implementing that logic in your authorization policies.

## Steps

1. Go to **Trust Framework**.

2. Click the tab of the appropriate Trust Framework element type, select the element that you want to test, and then click the **Test** tab.

3. Define the test scenario:

   1. In the **Domain** list, select any domains you want to include as request parameters.

   2. In the **Service** list, select any services you want to include as request parameters.

   3. In the **Identity Provider** list, select any identity providers (IdPs) you want to include as request parameters.

   4. In the **Action** list, select any actions you want to include as request parameters.

   5. In the **Attributes** list, select the attribute that you want to test and any other attributes that you want to include as request parameters, and provide sample values.

      |   |                                                                              |
      | - | ---------------------------------------------------------------------------- |
      |   | Click the angle brackets next to an attribute to display a JSON text editor. |

   6. In the **Overrides** section, configure attribute and service values if you want to override those elements' default behavior.

      For example, if an attribute is defined with a request parameter resolver and no value is specified in the test request, the decision engine resolves that attribute from the **Overrides** configuration.

      |   |                                                                                             |
      | - | ------------------------------------------------------------------------------------------- |
      |   | You can override any attribute's value, regardless of its resolution or processing details. |

   ### Example:

   The **Datetime** attribute defined in the following example has a value type of **Zoned Date Time**, resolves from a decision request parameter, and has no processors defined. Testing this attribute verifies whether the decision engine can directly convert this attribute from a string.

   ![Screen capture of the Datetime attribute defined with a Request Parameter resolver and a value type of Zoned Date Time](_images/datetime-attr-definition.png)

   The following scenario tests the **Datetime** attribute with an ISO 8601-formatted string as input:

   ![Screen capture of a Datetime attribute testing scenario with an ISO 8601-formatted representation of December 9, 2024 configured as input](_images/datetime-test-scenario.png)

4. Click **Execute**.

   |   |                                                                                                                                   |
   | - | --------------------------------------------------------------------------------------------------------------------------------- |
   |   | If the test scenario exceeds 50 kB in size, sample values will not be stored in the local cache after executing the test request. |

   ### Result:

   The **Output** tab displays the value and type of the attribute being tested.

   ![Screen capture of the Output tab displaying the result of the above Datetime test](_images/datetime-test-result.png)

5. Click the other tabs for additional details:

   * **Request**: Shows the JSON request sent to the decision, allowing you to confirm the expected information was sent.

   * **Response**: Shows the complete, high-verbosity response for the decision, including expanded errors and other helpful information.

     This tab can be helpful when troubleshooting value processing failures.

   * **Attributes**: Shows details about the attributes used in the decision.

   * **Services**: Shows details about the services used in the decision.

## Testing repeating attributes

Repeating attributes are resolved from values in a specified collection. A repeating attribute requires a repetition source that points to a collection. Additionally, to get its values from each repetition of the collection, the repeating attribute's resolver must be set to **Current Repetition Value**. When you properly configure a repeating attribute, you can test it the same way you test standard, nonrepeating attributes.

The **Output** tab in the test results will show results for each matching value from the collection. The results are ordered with indices that reflect the order of resolution.

Learn more about these variables in [Repeating policies and attributes](paz_repeat_pols_attrs.html).