# Testing and release checks

## Prerequisites and safety

Use a separate populated development/review tenant. API/browser suites create and clean synthetic tenants and require the project's existing test setup configuration. They are not production smoke tests. Run API and browser suites sequentially because fixture cleanup is shared.

Never point destructive fixture tests at production, log connection tokens, or commit private capture results. Running the documentation client with no `--tool` lists names only; its explicit tool mode is read-only, but results may still contain private records.

## Automated checks

From the workspace root:

```sh
pnpm --filter @workspace/api-server run test:unit
pnpm --filter @workspace/api-server run typecheck
pnpm --filter @workspace/scripts run typecheck

pnpm --filter @workspace/scripts exec vitest run --config vitest.config.ts \
  src/e2e/mcp.test.ts src/e2e/mcp-oauth.test.ts \
  src/e2e/mcp-outcomes.test.ts src/e2e/mcp-security.test.ts \
  src/e2e/mcp-documentation.test.ts

pnpm --filter @workspace/scripts exec playwright test --config playwright.config.ts \
  src/browser/tests/19-mcp-settings.spec.ts \
  src/browser/tests/20-mcp-oauth.spec.ts \
  src/browser/tests/21-mcp-native-views.spec.ts \
  src/browser/tests/22-mcp-security.spec.ts
```

MCP renderer/reference unit tests verify safe HTML and policy-source consistency. Documentation integration tests check public pages, downloads, links, catalogue controls and the runnable client against a real development connection.

## Required security scenarios

- Read-only grant cannot write; narrowed modules/actions/tools cannot regain excluded access.
- Tenant and record scopes exclude foreign/excluded UUIDs, including write references.
- Documents need both sharing grants; export, masking, row/byte and batch limits are enforced.
- Organization/user/connection quotas persist, and concurrent limits are enforced.
- Approval binds exact immutable arguments, expires, can be rejected and is single-use under concurrent execution.
- Changing policy invalidates approvals; disabling MCP permanently revokes old tokens.
- Re-enabling does not revive old credentials.
- Client display names do not bypass approved registration restrictions.
- OAuth PKCE/resource/redirect checks, code reuse and refresh-token replay are enforced.
- Native refresh/drill-down does not execute writes, bypass scopes or leak credentials.

## Real-provider checks

Connect a review account in each actual provider. Test account linking, expired authorization, direct/indirect/negative tool prompts, denied permissions and one approved write independently of UI.

In MCP Apps hosts test themes, mobile scrolling, refresh, fullscreen where supported and the checked application review link. In non-UI hosts inspect structured/text results and truthful warnings.

Run the separate discovery evaluation described in [Native views and discovery](../mcp-providers/native-views-and-discovery.md). Synthetic benchmarks are not consumer-provider verification and do not establish ranking or directory acceptance.

## Release and migrations

Keep development and production connections separate. Verify development schema first, then publish through the normal Publish flow. For an already-existing-table validation error, inspect both schemas read-only and recompute the Publish diff. Do not delete tables, rewrite migration history or introduce a competing production DDL runner.

After publication, create/link a least-privilege production connection and perform non-destructive reads. Directory submission, provider review and production publishing are human-controlled milestones, not effects of a successful local test run.