CMS FAQ Management — Automated UAT Tests

Automated validation suite for the CMS FAQ Management extension. Tests the FAQ API, BC OData endpoints, cross-system data consistency, and posted document preservation.

Overview

This test suite automates 17 of the 36 test cases from the UAT Test Plan (Epic 193). Tests are organized into three tiers based on their system dependencies:

Tier	Systems	Credential Requirements	Test Count
Tier 1	FAQ API only	FAQ_API_* env vars	7
Tier 2	BC OData only	BC_* env vars	~15
Tier 3	Both FAQ + BC	All env vars	5

A snapshot marker identifies tests that require pre-captured data (before/after comparisons).

Prerequisites

• Python 3.10+
• Access to the Bestway FAQ API (for tier 1 and tier 3 tests)
• Azure AD app registration with BC API permissions (for tier 2 and tier 3 tests)
• bc-csm-api extension v1.1.0.0 published to the BC sandbox (provides the OData endpoints)

Setup

cd "CMS FAQ Management/test"
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Copy .env.example to .env and fill in credentials:

cp .env.example .env

Variable	Description
FAQ_API_BASE_URL	FAQ API root URL
FAQ_API_USERNAME	FAQ login username
FAQ_API_PASSWORD	FAQ login password
BC_TENANT_ID	Azure AD tenant ID (GUID)
BC_CLIENT_ID	Azure AD app registration client ID
BC_CLIENT_SECRET	Azure AD app registration client secret
BC_ENVIRONMENT	BC environment name (default: sandbox)
BC_COMPANY_ID	BC company ID (GUID)

Running Tests

# All tests (skips automatically if credentials are missing)
pytest

# By tier
pytest -m tier1          # FAQ API only
pytest -m tier2          # BC OData only
pytest -m tier3          # Cross-system

# Snapshot tests only
pytest -m snapshot

# Exclude snapshot tests
pytest -m "not snapshot"

# Specific test file
pytest tests/test_tier1_faq_api.py

# Specific test
pytest tests/test_tier2_bc_data.py::TestFieldPopulation::test_table_has_records

Snapshot Workflow

Snapshot tests compare BC data before and after a specific operation. The workflow is:

1. Capture the "before" state using run_snapshot.py.
2. Trigger the operation manually in BC (full rebuild, incremental sync, etc.).
3. Capture the "after" state.
4. Run the snapshot tests — they load both snapshots and compare.

TC-1.2A: Full Rebuild Inactivation

Verifies that a full rebuild marks pre-existing records inactive (rather than deleting them).

python run_snapshot.py capture pre
# → In BC: trigger a full rebuild via the FAQ Management page
python run_snapshot.py capture post
pytest -m snapshot -k "rebuild_inactivation"

TC-1.2B / TC-5.3A: Rebuild Idempotency

Verifies that running a full rebuild twice produces identical results.

python run_snapshot.py capture post_rebuild_1
# → In BC: trigger a second full rebuild
python run_snapshot.py capture post_rebuild_2
pytest -m snapshot -k "idempotency"

TC-9.1 / TC-9.2: Posted Document Preservation

Verifies that posted service invoices and shipments are not modified by a sync.

python run_snapshot.py capture pre_sync
# → In BC: trigger a sync (full or incremental)
python run_snapshot.py capture post_sync
pytest -m snapshot -k "preservation"

Managing Snapshots

# List all captured snapshots
python run_snapshot.py list

Snapshots are saved as JSON files in the snapshots/ directory (gitignored). Each snapshot contains one JSON file per table plus a metadata.json with timestamps and row counts.

Test Case Mapping

TC	Description	File	Tier
TC-1.1	API Authentication	test_tier1_faq_api.py	1
TC-1.2A	Full Rebuild Inactivation	test_tier2_snapshots.py	2/snapshot
TC-1.2B	Full Rebuild Idempotency	test_tier2_snapshots.py	2/snapshot
TC-3.1	Sync Field Presence	test_tier2_bc_data.py	2
TC-3.2	Field Population	test_tier2_bc_data.py	2
TC-3.3	Mapping Integrity	test_tier3_cross_system.py	3
TC-4.1	Code Correlation	test_tier3_cross_system.py	3
TC-4.3	Code Uniqueness	test_tier1_faq_api.py + test_tier2_bc_data.py	1 + 2
TC-5.3A	Rebuild Idempotency	test_tier2_snapshots.py	2/snapshot
TC-8.1	Hierarchy Mapping	test_tier1_faq_api.py + test_tier3_cross_system.py	1 + 3
TC-8.2	Relationship Tables	test_tier1_faq_api.py + test_tier2_bc_data.py	1 + 2
TC-8.3	Service Item Group	test_tier2_bc_data.py	2
TC-9.1	PSI Preservation	test_tier2_snapshots.py	2/snapshot
TC-9.2	SO Preservation	test_tier2_snapshots.py	2/snapshot

Project Structure

CMS FAQ Management/test/
├── README.md                       # This file
├── requirements.txt                # Python dependencies
├── .env.example                    # Credential template
├── .gitignore                      # .env, .venv/, snapshots/
├── pytest.ini                      # Markers, test paths, verbosity
├── conftest.py                     # Fixtures, skip logic, client setup
├── run_snapshot.py                 # CLI for capturing/listing snapshots
├── tests/
│   ├── __init__.py
│   ├── test_tier1_faq_api.py       # FAQ API tests (TC-1.1, 4.3, 8.1, 8.2)
│   ├── test_tier2_bc_data.py       # BC data tests (TC-3.1, 3.2, 4.3, 8.3)
│   ├── test_tier2_snapshots.py     # Snapshot tests (TC-1.2A/B, 5.3A, 9.1, 9.2)
│   └── test_tier3_cross_system.py  # Cross-system tests (TC-3.3, 4.1, 8.1)
└── snapshots/                      # Captured snapshots (gitignored)
    └── .gitkeep

Shared Dependencies

The test suite imports shared modules from tools/ at the repository root:

Module	Purpose
tools/bc_odata_client.py	OAuth2 client for BC OData v4 endpoints
tools/faq_api_client.py	FAQ API client
tools/snapshot_lib.py	Snapshot capture, load, and diff

These are imported via sys.path.insert in conftest.py — no package installation required.

Known Limitations

1. FAQ Management extension only adds Status to Fault Area. The CMS FAQ Management extension (Sataware Technologies) adds a single Status field to the Fault Area table only — not to Symptom Codes, Fault Codes, or Resolution Codes. TC-3.1 validates this field on Fault Areas. The CSM API Toolkit v1.5.0.0 exposes it via OData.

2. Cross-system mapping tests are approximate. TC-3.3 and TC-4.1 verify that both systems have data, but the exact FAQ→BC field mapping (which FAQ field maps to which BC column) needs to be confirmed after the extension is deployed. Tests will be tightened once the mapping is known.

3. Snapshot tests require manual BC operations. The "trigger sync" step between snapshot captures must be done manually in BC. These tests cannot run fully unattended.