# Use Test Fixtures

Test fixtures give you a known, repeatable project source to use when validating connection, analysis, and documentation results. They help you separate configuration problems from differences in a live repository.

## Overview

A test fixture is a controlled set of source material used for development testing. Because the source is known, you can run the same test more than once and compare the results with confidence. Use fixtures before testing against a production repository, after changing a provider connection, or when investigating unexpected documentation output.

Fixtures are especially useful for validating that Atloria identifies common application areas consistently. A fixture may include frontend components, backend services, database-related items, API schemas, configuration, documentation, and infrastructure content. During analysis, these areas are organized through stages such as **FRONTEND**, **BACKEND**, **DATABASE**, **API SCHEMA**, **CONFIG**, **DOCUMENTATION**, and **INFRASTRUCTURE**.

Use a fixture as your baseline. First confirm that the fixture connection and analysis work as expected. Then, if a live project behaves differently, you can focus on the differences in the live project rather than retesting your entire Atloria setup.

> 📷 _Screenshot pending: Development testing view showing a fixture project and available test actions._

## Prerequisites

Before you begin, make sure you have:

- Access to the Atloria project setup and testing screens.
- A test fixture prepared or assigned by your development-testing administrator.
- Access to the fixture’s configured Git provider, if the fixture is provider-based.
- Permission to use **Connect Provider** and complete provider selection.
- The correct provider credentials or authorization available for the fixture.
- A clear expected result for the test, such as successful connection, successful agent test, or generated documentation that can be reviewed.
- A documented baseline for comparison if you are repeating an existing test.

## Step-by-Step Instructions

1. **Open the fixture project or create a dedicated test project.**

   Use a project reserved for development testing rather than a live production project. In the project setup flow, select **Connect Provider** to begin connecting the fixture source.

   If you are reviewing an existing test project, confirm that it is clearly named as a fixture or test project before continuing. This helps prevent you from generating or exporting documentation from the wrong source.

2. **Select the fixture’s Git provider.**

   On the provider-selection step, choose the provider that hosts the fixture. The screen identifies this stage as **Git Providers** and may display a numbered step such as **1. Provider Selection** or **4. Provider Selection**.

   Select the configured provider and complete the authorization requested by your organization. A fixture should use the same provider configuration each time you repeat a test unless you are specifically testing provider behavior.

3. **Verify the provider connection.**

   Click **Test Connection** after selecting or configuring the provider. If your screen presents the action with an icon, it may appear as **⚡ Test Connection**.

   Wait for the test to complete before changing any other setting. Record whether the connection succeeded and, if relevant, the date, provider, and fixture project used. A successful connection confirms that Atloria can reach the fixture source; it does not yet confirm that the source can be analyzed successfully.

4. **Test the analysis agent.**

   Click **Test Agent** to verify that the analysis process can work with the fixture. Use the same fixture version for repeated tests so that changes in results are easier to identify.

   If your testing workflow includes an event-based connection, click **⚡ Test Webhook** as well. This confirms that the configured test event can reach Atloria. Do not treat a webhook test as a replacement for **Test Agent**; each action validates a different part of the testing workflow.

5. **Generate documentation from the fixture.**

   After the connection and agent tests succeed, select **Generate Documentation →**. Keep the test focused: use the same fixture and settings when you are validating repeatability.

   As Atloria analyzes the fixture, review whether the resulting documentation reflects the expected categories. For example, a full application fixture can produce documentation covering frontend elements, backend logic, database-related content, API schema details, configuration, and documentation material.

6. **Review the generated result.**

   Select **View Your Documentation →** to open the generated documentation. Compare the result with your expected baseline.

   When source review is available, use **View Source** or **Source** to inspect the source context associated with the generated result. This is useful when a documented item appears incomplete or unexpected: you can verify whether the fixture contains the expected source material before assuming that the result is incorrect.

   > 📷 _Screenshot pending: Generated documentation with the “View Source” and “Source” actions available for fixture-result review._

7. **Record and repeat the test.**

   Record the fixture name or version, provider used, test actions completed, and outcome. For a repeatability check, run the same fixture again without changing the source or setup. Compare the documentation result, including its identified categories and relationships, against the prior baseline.

   If the results are consistent, the fixture has provided a successful repeatable test. If they differ, use the comparison to determine whether the change came from the fixture, provider configuration, analysis environment, or documentation settings.

## Tips and Best Practices

- **Keep fixtures stable.** Do not change fixture source content while you are validating repeatability. If the source changes, treat it as a new fixture version and create a new baseline.

- **Use fixtures before live repositories.** A fixture is the safest place to test provider selection, connection checks, agent behavior, webhook delivery, and documentation generation without introducing live-project variation.

- **Test one change at a time.** For example, if you change provider credentials, test the connection first. Do not also change the fixture source or documentation settings in the same run.

- **Use the correct test action for the question.** Choose **Test Connection** to confirm access, **Test Agent** to confirm analysis readiness, and **⚡ Test Webhook** to confirm event delivery.

- **Review source when output is unexpected.** Use **View Source** or **Source** during result review. This helps you determine whether a missing or unusual documentation item is absent from the fixture or was not represented as expected.

- **Export only reviewed results.** Select **Export Documentation** only after you have reviewed the generated fixture documentation and confirmed that it is clearly marked as test output.

## Related Pages

- [Connect a Git Provider](#)
- [Test a Provider Connection](#)
- [Test Agent Access](#)
- [Test Webhook Delivery](#)
- [Generate Documentation](#)
- [Review Generated Documentation](#)
- [Export Documentation](#)

## Troubleshooting

### The fixture cannot connect to its provider

**Problem:** **Test Connection** or **⚡ Test Connection** does not succeed.

**Cause:** The selected Git provider, authorization, or fixture repository access may not match the configured test fixture.

**Solution:** Return to **Connect Provider**, confirm the correct choice under **Git Providers**, and repeat provider authorization if required. Then run **Test Connection** again before attempting **Test Agent** or **Generate Documentation →**.

### The connection succeeds, but the fixture cannot be analyzed

**Problem:** **Test Connection** succeeds, but **Test Agent** does not complete successfully.

**Cause:** Provider access confirms that Atloria can reach the fixture, but the analysis test may still be unable to process the selected fixture source or its current configuration.

**Solution:** Confirm that you are using the intended fixture version and that it has not changed since the baseline was recorded. Run **Test Agent** again, then review the fixture setup. If the workflow uses events, also run **⚡ Test Webhook** and provide the recorded test results to your development-testing administrator.

### Generated documentation differs from the previous fixture result

**Problem:** The documentation generated from the same fixture does not match the baseline.

**Cause:** The fixture source, provider configuration, analysis settings, or generated-documentation state may have changed between tests.

**Solution:** Use **View Your Documentation →** to compare the output, then select **View Source** or **Source** to confirm the source context. Verify the fixture version and test setup against your recorded baseline. If the source and setup are unchanged, record the difference and escalate it with the fixture name, test date, and completed test actions.