These are end-to-end tests that run against a real Microsoft Fabric workspace
(gated behind the integration pytest marker) and exercise the shared service layer
that both the CLI and MCP server delegate to.
The service layer calls either the Fabric REST API via http_client.py or the
warehouse TDS endpoint via sql.py; both paths hit real Fabric infrastructure
during these tests.
A ✅ means the shared service function behind the feature has been called against a real Fabric workspace and its result has been asserted.
The service layer is the common path that both the CLI and the MCP server delegate to:
CLI (Click command) ──┐
├──► service function ──► http_client / sql.py ──► real Fabric API
MCP (FastMCP tool) ───┘
So a ✅ in "Integration test" gives confidence that the Fabric API contract is honoured: the correct HTTP calls are made, pagination and LRO polling work, and the response is deserialised correctly.
The integration tests provision two ephemeral fixtures:
An ephemeral Data Warehouse (ephemeral_warehouse / ephemeral_sql_target in conftest.py) used by warehouse-focused tests (tables, views, schemas, stored procedures, audit, snapshots, restore points, queries, query insights, sql exec).
A schema-enabled Lakehouse with its paired SQL Analytics Endpoint (ephemeral_lakehouse / ephemeral_sql_endpoint in conftest.py) used by the SQL Analytics Endpoint tests. The Lakehouse is created with enableSchemas=true; Fabric auto-provisions the SQL endpoint alongside it. The fixture polls until provisioning reaches Success (up to 5 minutes) and skips rather than fails if it does not complete in time.
The one remaining ❌ in the coverage table (restore-points restore) is not run in standard CI:
restore_in_place has an integration test (test_restore_in_place_reverts_warehouse_state) but it is skip-guarded behind FABRIC_RESTORE_IN_PLACE_TESTS because the LRO takes ~10 minutes, making it impractical as an automated gate. It is covered by unit tests with full LRO mocking.
The integration tests do not exercise the upper adapter layers:
CLI layer — Click argument parsing, output rendering (Rich tables / JSON), and the mapping of service exceptions to click.ClickException / exit codes. These are covered by unit tests in tests/unit/cli/.
MCP tool layer — FastMCP tool registration, the _guards.py security middleware (readonly / destructive / allowlist guards, row-cap enforcement), and the fabric_err error-funnel. These are covered by unit tests in tests/unit/mcp/. In particular, the MCP security guards are unit-tested only and do not run during integration tests.
Config, cache, and completion commands — config show/set/unset/clear, cache clear, and completion install are local-state operations that do not call the Fabric API and therefore have no integration tests.
The CLI and MCP columns indicate only whether the feature is exposed in that frontend — they say nothing about integration-test coverage of those frontends.
Every operation listed has both a CLI command and an MCP tool; the CLI and MCP columns are ✅ across the board for all operations listed above.
warehouses.create is exercised indirectly via the ephemeral_warehouse fixture in conftest.py (line 44), which is shared by dozens of tests. ↩
sql-endpoints permissions delegates to permissions.list_item_access, which is item-type-agnostic. The integration test at line 70 exercises the non-admin error path against a live warehouse item (the same code path the endpoint follows); the admin happy-path (lines 44 and 57) is conditionally skipped unless FABRIC_TEST_IS_TENANT_ADMIN=1 is set. Note: FABRIC_TEST_IS_TENANT_ADMIN gates the tenant-level Fabric Administrator role (distinct from workspace-level Admin/Contributor membership), which is required to call the /v1/admin/... endpoints. ↩
list_sql_pools reads the same configuration response as get_configuration; the test_get_configuration_returns_model test covers that path. ↩
get_sql_pool reads a named pool from the same configuration response; covered by the same test. ↩
restore_in_place is not run in standard CI: the integration test test_restore_in_place_reverts_warehouse_state (tests/integration/test_services_restore.py#L119) is skip-guarded behind the FABRIC_RESTORE_IN_PLACE_TESTS environment variable because restore_in_place takes ~10 minutes for the LRO to complete, making it impractical as an automated gate. It is covered by unit tests with full LRO mocking, and can be run manually by setting FABRIC_RESTORE_IN_PLACE_TESTS=1. ↩
The point-in-time clone test (clone_table with an AT timestamp) is skipped at runtime when the engine rejects the timestamp because the freshly-created source table has no committed history at the requested instant. This is an expected SQL engine constraint, not a code defect; the code path is verified on every run where the engine accepts the timestamp. ↩
The test_create_list_delete_roundtrip test at line 83 covers plain delete. A dedicated cascade test at line 105 covers delete_schema(cascade=True), which drops contained tables before dropping the schema. ↩
The integration test for kill validates input-validation errors against a live warehouse; it does not kill a running session (none exist on an ephemeral warehouse). The happy-path kill path is covered by unit tests. ↩