Read-Only Integration Test Plan¶

Document status: Planned verification
Verification status: Execution evidence pending
Scope: Gmail, Google Drive, Google Calendar, Jira, Slack, and Microsoft Teams

1. Purpose¶

This document defines the test scenarios, verification procedures, and acceptance criteria required to validate WhiteLotusAI's integrations in strict read-only mode.

The objective is to demonstrate that:

• Approved read operations return only data authorized for the requesting user.
• Write-capable operations are rejected at the appropriate server-side enforcement boundaries.
• Authentication, authorization, OAuth, and credential handling fail safely.
• Provider errors, malformed inputs, and dependency failures do not compromise security or expose sensitive information.
• Verification results are reproducible, traceable, and tied to a specific application version.

This document is a test plan, not evidence of implementation or successful execution. A requirement must not be considered verified solely because it appears in this document.

2. Scope and Boundaries¶

2.1 Integrations in scope¶

The plan also covers tool registration and dispatch, direct integration API access, internal service authentication, user isolation, OAuth security, input validation, error handling, and security-relevant logging.

2.2 Out of scope¶

• Implementing application-code changes.
• Introducing new integration capabilities or broader OAuth scopes.
• Using production credentials or real customer data.
• Performing live write operations to demonstrate that writes should be blocked.
• Declaring production readiness without supporting test and deployment evidence.

3. Test Status and Evidence¶

Use the following status values consistently:

A blocked test is not a pass. An unavailable test dependency must not be silently treated as successful verification.

4. Test Environment and Safety Controls¶

Execute the plan only in an isolated development or test environment.

4.1 Pre-execution checklist¶

• Use dedicated test accounts and synthetic or approved test data.
• Confirm that production credentials and customer records are not being used.
• Identify the application commit, build, and configuration under test.
• Review manual scripts and test fixtures for external side effects.
• Confirm that write-operation tests use mocks, controlled provider fixtures, or an isolated test tenant.
• Verify that rejected write operations cannot reach the provider's mutation endpoint.
• Ensure test logs, screenshots, and reports redact credentials and sensitive content.
• Record missing dependencies and environmental limitations before execution.

4.2 Required test layers¶

The suggested methods are test-design recommendations. Use only commands, fixtures, and test infrastructure that actually exist in the repository or have been deliberately created for the test environment.

5. Verification Workflow¶

The following workflow describes the expected verification process. It does not imply that these stages have already been executed.

flowchart TD
    A["Identify application version"] --> B["Prepare isolated test environment"]
    B --> C["Review test prerequisites and safety"]
    C --> D["Execute functional read tests"]
    D --> E["Execute write-prevention tests"]
    E --> F["Verify identity, OAuth, and authorization"]
    F --> G["Exercise failure and regression scenarios"]
    G --> H{"Evidence meets acceptance criteria?"}
    H -- "No" --> I["Record failure or blocked status"]
    I --> J["Create or update defect record"]
    J --> G
    H -- "Yes" --> K["Review evidence and outstanding risks"]
    K --> L{"All exit criteria satisfied?"}
    L -- "No" --> I
    L -- "Yes" --> M["Record version-scoped verification result"]

    classDef process fill:#e8efff,stroke:#5678b8,color:#172b4d
    classDef decision fill:#fff0d6,stroke:#b7791f,color:#633c08
    classDef outcome fill:#dff5e8,stroke:#26845b,color:#164b35
    class A,B,C,D,E,F,G,I,J,K process
    class H,L decision
    class M outcome

The diagram uses explicit node colors for readability. If the documentation renderer does not provide sufficient contrast in both themes, remove the classDef and class lines while retaining the workflow.

6. Common Test Scenarios¶

Each scenario must be executed against the appropriate enforcement boundary. Where a scenario applies to several integrations, record results separately for each applicable provider.

6.1 Write-prevention enforcement matrix¶

Write prevention must be tested at every applicable layer rather than inferred from the user interface.

A successful chat-level rejection does not prove that a direct API route is protected. Likewise, a missing frontend control is not evidence that a server-side authorization check exists.

7. Integration-Specific Test Scenarios¶

7.1 Gmail¶

7.2 Google Drive¶

7.3 Google Calendar¶

7.4 Jira¶

7.5 Slack¶

7.6 Microsoft Teams¶

8. OAuth and Credential Security¶

Apply the following scenarios to each integration that uses OAuth or equivalent delegated credentials. Tailor the tests to the actual authorization flow and provider requirements.

OAuth state validation, PKCE, and callback replay controls must be assessed according to the actual flow. Do not assume that every provider or authorization path uses identical mechanisms.

9. Input Validation, Reliability, and Information Security¶

In addition to the scenario tables above, verify the following controls.

9.1 Input and resource bounds¶

• Missing, empty, malformed, or excessively long identifiers.
• Unsupported search operators and invalid query syntax.
• Invalid date ranges and inconsistent pagination parameters.
• Zero, negative, nonnumeric, or excessive result limits.
• Oversized attachment downloads or unexpected content types, where applicable.
• Provider responses containing missing fields, unexpected types, or invalid encodings.

Acceptance requires deterministic validation or controlled failure, bounded resource use, and no unintended external side effects.

9.2 Reliability and dependency failures¶

• Provider connection timeouts and request failures.
• HTTP throttling and provider rate-limit responses.
• Internal database, cache, and message-broker failures where relevant to the request path.
• Token-store failures during lookup, refresh, or persistence.
• Repeated failures and retry behavior.
• Cancellation or interrupted requests, where supported.

Retries must not convert a rejected mutation into an executable operation. Retry behavior must be bounded and consistent with the applicable provider guidance.

9.3 Security and observability¶

• Verify that access tokens, refresh tokens, authorization codes, and internal secrets are not exposed in responses or logs.
• Verify that error responses do not reveal stack traces, database details, or internal service credentials.
• Verify that security-relevant events can be correlated with a request or test identifier without logging unnecessary message or document content.
• Verify that authorization failures do not reveal whether another user's private resource exists, beyond what the documented API intentionally discloses.
• Verify that failure status is observable and accurately represented in test reports.

10. Test Execution and Evidence Record¶

10.1 Required evidence fields¶

Record one entry for every executed scenario.

10.2 Example test-result record¶

The following YAML is a template only. Replace the placeholders with actual execution data before using it as evidence.

test_id: RO-003
application_version: "<commit-sha-or-build-id>"
environment: "<isolated-test-environment>"
preconditions:
  - "Dedicated test account configured"
  - "Provider mutation endpoint instrumented or mocked"
execution:
  command: "<actual-test-command>"
expected_result: "Direct write request is rejected server-side."
actual_result: "<observed-result>"
status: "Not Run"
evidence:
  - "<sanitized-test-report-or-log-reference>"
defect_reference: null
reviewer: "<reviewer-or-pending>"

Do not fabricate observed results, report links, commit identifiers, or reviewer approvals.

10.3 Suggested execution commands¶

Use the repository's actual test configuration and installed tooling. The following commands are illustrative examples, not assertions that the project exposes these exact test paths or scripts.

# Run an existing, verified test module.
pytest <existing-test-path> -q

# Inspect the current version and working-tree state.
git rev-parse HEAD
git status --short

1. Confirm the recorded version matches the tested build.
2. Review the assertion output and sanitized logs.
3. Verify that negative tests did not reach provider mutation methods.
4. Record the final status and any defect reference.

Only record commands that were actually executed. A successful test-runner exit code alone is insufficient if the relevant test was skipped, did not execute, or failed to assert the intended security property.

11. Exit Criteria¶

Strict read-only mode must not be declared verified until all applicable criteria below are satisfied.

• Approved read-operation tests pass for the six integrations in scope.
• Identified write-capable operations are blocked through applicable tool-dispatch and direct API paths.
• Tests confirm that rejected mutations do not reach provider mutation methods.
• Authentication, authorization, and cross-user isolation tests pass.
• Applicable OAuth, token refresh, and credential persistence tests pass.
• Input validation, result bounds, and failure-handling tests pass.
• Security-relevant logs and error responses meet project requirements.
• Relevant regression tests pass.
• Every failure and blocked test has a documented disposition.
• Evidence is reviewed and corresponds to the application version proposed for release.

A test that is inapplicable must have a documented rationale. A blocked or failed critical security test must not be treated as satisfying an exit criterion without an explicit, approved risk decision.

12. Maintenance and Change Control¶

Review this plan whenever any of the following changes:

• Integration tools, registry entries, or dispatch behavior.
• API routes or authorization enforcement.
• OAuth scopes, callback handling, or token lifecycle management.
• Provider permissions or credential-resolution behavior.
• Read-only requirements, supported operations, or result limits.
• Logging, error handling, or security-sensitive dependencies.

When a defect is fixed, add or update a regression test that demonstrates the required behavior. Keep implementation changes, test evidence, and documentation changes separately traceable.

Re-evaluate previously passed tests when relevant code, dependencies, permissions, or deployment configuration changes.

13. Related Documentation¶

Link these references to their actual repository paths when the corresponding documents are available:

• Security Overview
• Threat Model
• Read-Only Integration Security Policy
• Testing Strategy
• Test Cases
• Test Inventory

Verification principle: A documented control is a requirement. An executed test with reproducible evidence is verification. A release decision requires both the relevant evidence and a documented review.