> ## Documentation Index
> Fetch the complete documentation index at: https://holder.docs.fiskil.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing CDR

> Plan and run user acceptance testing (UAT) of your CDR Data Holder solution in Fiskil's hosted CDR ecosystem.

Before you go live as a Data Holder, test your solution end to end in Fiskil's **UAT environment**. Fiskil hosts and manages a complete CDR ecosystem for this purpose, so you can validate consent, data sharing, error handling, and revocation without connecting to the live ACCC register.

The UAT environment is a web portal with a **Mock Data Recipient**. It simulates the consent process and the data requests that accredited Data Recipients (ADRs) make in the live CDR ecosystem.

***

## How testing works

**1. Set up access**

Send Fiskil the list of team members who need access, and prepare your test customers. See [Set up the UAT environment](https://holder.docs.fiskil.dev/api-reference/cdr/testing/uat-environment.md).

**2. Prepare your test personas**

Choose test customers that cover single-account, multi-account, and business-account scenarios. See [Test personas](https://holder.docs.fiskil.dev/api-reference/cdr/testing/test-personas.md).

**3. Run the four test phases**

Work through the phases in order. Each phase relies on the one before it, and you should run every phase for each persona.

**4. Report defects**

Raise any issues you find as a ticket in the Fiskil Console. See [Report defects and get support](https://holder.docs.fiskil.dev/api-reference/cdr/testing/reporting-defects.md).

***

## Test phases

> **[Phase 1: Consent authorisation](https://holder.docs.fiskil.dev/api-reference/cdr/testing/consent-authorisation.md)**
>
> Create consents through the Pushed Authorisation Request (PAR) flow and review the consent screens.

> **[Phase 2: Data validation](https://holder.docs.fiskil.dev/api-reference/cdr/testing/data-validation.md)**
>
> Call the Banking and Energy APIs and confirm each persona receives correct, standards-compliant data.

> **[Phase 3: Error validation](https://holder.docs.fiskil.dev/api-reference/cdr/testing/error-validation.md)**
>
> Send invalid requests and confirm the correct CDS error codes and HTTP status codes are returned.

> **[Phase 4: Consent dashboard and revocation](https://holder.docs.fiskil.dev/api-reference/cdr/testing/consent-dashboard.md)**
>
> Review consents in the consumer dashboard, withdraw a consent, and confirm data sharing stops.

***

## UAT limitations

> [!WARNING]
>
> Some parts of the CDR cannot be fully tested in UAT because of CDR authentication requirements. These include, but are not limited to:
>
> * **Admin APIs** (for example, Get Metrics and Metadata Update)
> * **Reporting**
> * **AEMO APIs** (Energy service points, usage, and DER data)
> * **Non-functional requirements (NFRs)**, such as performance and availability thresholds
> * **Plans data**, which relies on AER data

For the requirements that apply to these areas in production, see [Non-Functional Requirements](https://holder.docs.fiskil.dev/api-reference/cdr/cdr-nfrs.md) and the [CDR FAQs](https://holder.docs.fiskil.dev/api-reference/cdr/cdr-faqs.md).

***

## Related

* [Integration requirements](https://holder.docs.fiskil.dev/api-reference/cdr/integration-requirements.md)
* [Errors](https://holder.docs.fiskil.dev/api-reference/cdr/errors.md)
* [Testing and validation overview](https://holder.docs.fiskil.dev/docs/testing.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.