Test Inventory¶

This document inventories test files and manual test scripts identified in the available WhiteLotusAI repository snapshot. It records their locations, apparent testing scope, execution considerations, and areas requiring further verification.

The inventory supports test discovery and maintenance. It does not independently establish test correctness, verified coverage, or release readiness.

1. Inventory at a glance¶

Counting note: These figures reflect the files listed in this inventory, not a verified count of all test files in the repository. Repository-level scripts may overlap with service-level test coverage, and the inventory should be reconciled against the current checkout before release.

2. Service test inventory¶

The following table identifies the service-level test modules and their apparent scope.

Review guidance¶

Before assigning a test module to a specific coverage requirement:

• Inspect the test implementation and its assertions.
• Review conftest.py files, fixtures, mocks, and shared configuration.
• Confirm that tests fail when the behavior they protect is deliberately broken.
• Distinguish isolated unit tests from tests requiring external services.
• Record execution results separately from repository inspection findings.

3. Repository-level test scripts¶

The repository snapshot also contains scripts that exercise integration workflows. These are operationally different from isolated unit tests and may modify persistent connection state.

Security requirements before execution¶

Before executing or committing a manual test script:

1. Inspect the complete script, including sourced files and subprocesses.
2. Check for passwords, OAuth tokens, internal secrets, and production identifiers.
3. Replace sensitive literals with environment variables and use dedicated test credentials.
4. Confirm that API endpoints, database connections, and service URLs target an isolated test environment.
5. Identify all possible side effects, including token persistence and connection-state changes.
6. Ensure the script cannot send messages, modify real user resources, or affect production data.
7. Rotate any real credential found in source control according to the organization's incident-response process.

4. Test workflow and evidence¶

The following diagram illustrates the recommended process for turning an identified test artifact into recorded verification evidence.

flowchart TD
    A["Identify test artifact"] --> B["Inspect implementation and fixtures"]
    B --> C["Review dependencies and side effects"]

    G -- "Yes" --> H["Record command, environment, and result"]
    H --> L["Update verification status"]
    D -- "Yes" --> F["Execute approved test command"]
    F --> G{"Expected result observed?"}
    G -- "No" --> I["Record failure and investigate"]
    I --> J["Create or link a defect"]
    J --> K["Add regression coverage after fix"]

    C --> D{"Safe isolated environment?"}
    D -- "No" --> E["Isolate dependencies and test data"]
    E --> C

    K --> F

    classDef work fill:#DCEBFA,stroke:#3975B7,color:#17365D,stroke-width:1.3px
    classDef decision fill:#FCE8CF,stroke:#B7791F,color:#704214,stroke-width:1.3px
    classDef issue fill:#F9DEDC,stroke:#B3261E,color:#7F1D1D,stroke-width:1.3px
    classDef done fill:#D9F2E6,stroke:#23835B,color:#174B37,stroke-width:1.3px

    class A,B,C,E,F,H work
    class D,G decision
    class I,J,K issue
    class L done

Recommended evidence record¶

For each meaningful test run, retain the following information in the team's approved reporting system:

Do not include secret values, access tokens, private message content, or other sensitive data in execution logs.

5. Coverage gaps requiring verification¶

The following areas are recommended verification targets. Their inclusion does not prove that tests are absent elsewhere in the repository.

5.1 Integration security¶

5.2 Read-only policy enforcement¶

5.3 AI orchestration and agent behavior¶

5.4 Operational reliability¶

6. Running tests safely¶

There is no single test command that can be assumed to work for every service and script. Determine the supported command from the relevant project configuration and dependency setup.

6.1 Execution checklist¶

• Confirm the correct repository revision and working tree.
• Inspect the test module, fixtures, configuration, and setup instructions.
• Identify required environment variables and external dependencies.
• Use isolated databases, dedicated test accounts, and non-production credentials.
• Verify that the test cannot modify real user resources or trigger unintended external actions.
• Run the supported command and capture the actual exit status.
• Review failures, skipped tests, warnings, and unexpected side effects.
• Store the execution evidence and update the inventory only when justified.

6.2 Command template¶

Use the command appropriate to the selected service and its project configuration. The following is a template, not a claim that this exact command has been validated for every service.

# Run from the relevant service/package directory.
# Replace the placeholder with an actual test module.
pytest <path-to-test-module> -v

For a shell-based integration test, first inspect its contents and prerequisites:

# Review the script before execution.
sed -n '1,240p' tests/test_plugin_connections.sh

# Execute only after confirming that its target environment is isolated.
bash tests/test_plugin_connections.sh

The second command is intentionally conditional: do not execute the script until its endpoints, credentials, and possible state changes have been reviewed.

7. Reporting and verification status¶

Use the following terminology consistently across testing documentation and release reports.

These statuses are evidence labels, not a substitute for a test report. For example, a test can be Identified without being Reviewed, and a successful command does not establish that the assertions provide adequate coverage.

Coverage reporting rules¶

• Do not report coverage percentages unless they come from a reproducible coverage process.
• Do not equate the number of test files or test cases with verified code coverage.
• Distinguish skipped tests from passing tests.
• Do not describe a test as passed without an actual execution result.
• Record the revision and environment associated with every reported result.
• Keep source-inspection findings separate from runtime verification evidence.

8. Maintenance and release review¶

Update this inventory whenever test files are added, removed, renamed, or materially changed.

Before each release:

• Reconcile the listed paths with the actual repository.
• Review test descriptions against current assertions.
• Reassess script prerequisites and security implications.
• Identify new or unresolved coverage requirements.
• Link the latest relevant test execution evidence.
• Confirm that failed, blocked, and unverified tests are represented accurately.

For maintainability, keep this inventory focused on what testing artifacts exist and what they establish. Detailed test procedures belong in the testing strategy or service-specific documentation; release acceptance decisions belong in the release process.

Related documentation: Testing Strategy · Test Cases · Read-Only Integration Security Policy

Document scope: This inventory records testing artifacts identified in the available repository snapshot. It does not certify production readiness, replace a security review, or establish that the documented requirements are implemented.