[Feature]: Enrich e2e test coverage for remaining MCP tools

[dongjiang1989]

Background

The e2e test suite (tests/e2e/) currently focuses on four areas:

File	Coverage
test_01_smoke.py	Basic connectivity (ds_test_connection)
test_02_auth.py	Authentication flows
test_03_project_crud.py	Project CRUD (ds_list_projects, ds_create_project, ds_rename_project, ds_delete_project)
test_06_negative.py	Negative / error paths

However, the server exposes 59 tools across 11 modules, and the remaining modules have zero e2e coverage:

Module	# Tools	E2E covered?
datasource.py	1	❌
instance.py	13	❌
monitor.py	2	❌
resource.py	10	❌
schedule.py	7	❌
user.py	2	❌
workflow.py	6	❌
workflow_advanced.py	8	❌
raw.py	4	❌
help.py	1	❌

That means roughly 54 out of 59 tools are only exercised by unit tests (if at all). Real end-to-end behavior — MCP serialization, multi-tenant auth headers, pagination handling, REST API contract drift against a live DolphinScheduler — goes unverified for the vast majority of the surface area.

Proposed Solution

Add dedicated e2e test files per module, following the existing naming convention and fixtures in tests/e2e/conftest.py:

• test_04_datasource.py — ds_list_datasources
• test_05_instance.py — lifecycle: ds_list_process_instances → ds_run_workflow (fixture) → ds_stop_process_instance / ds_pause_process_instance / ds_resume_process_instance / ds_rerun_process_instance / ds_rerun_from_failure, plus task-level: ds_list_task_instances, ds_get_task_log, ds_force_task_success, ds_skip_task, ds_get_latest_failure_log, ds_delete_process_instance, ds_complement_data
• test_07_monitor.py — ds_monitor_masters, ds_monitor_workers
• test_08_resource.py — folder/file lifecycle: ds_create_folder → ds_online_create_file → ds_upload_file → ds_list_resources → ds_view_resource → ds_get_resource_by_name → ds_download_resource → ds_update_resource_content → ds_rename_resource → ds_delete_resource
• test_09_schedule.py — ds_list_schedules, ds_set_schedule, ds_online_schedule, ds_offline_schedule, ds_update_schedule_cron, ds_delete_schedule, ds_put_lite
• test_10_user.py — ds_list_users, ds_list_tenants
• test_11_workflow.py — ds_create_workflow → ds_list_workflows → ds_get_workflow → ds_run_workflow → ds_release_workflow → ds_delete_workflow
• test_12_workflow_advanced.py — ds_update_workflow, ds_get_task_detail, ds_list_workflow_versions, ds_rollback_workflow_version, ds_clone_workflow, ds_create_dag_workflow, ds_modify_workflow_dag, ds_update_task_param
• test_13_raw.py — ds_raw_get, ds_raw_post, ds_raw_put, ds_raw_delete
• test_14_help.py — ds_help

Guidelines

1. Reuse existing fixtures. The mcp_client and unique_project_name fixtures in conftest.py already handle cluster bootstrapping. Add new fixtures (e.g., workflow_with_tasks, resource_folder) at the module level when downstream tests need pre-created state.
2. Ordered tests with shared state. Follow the TestXxx class + test_01_*, test_02_* pattern used by TestProjectCRUD so create/list/update/delete flows stay deterministic.
3. Idempotent cleanup. Every test that creates a resource must clean it up in a final test_NN_teardown step (or a class-level fixture), so repeated runs against the same cluster don't accumulate state.
4. Assert on MCP wire format, not just payloads. At least one assertion per tool should verify the JSON-RPC structure (no error key, result.content[0].type == "text", parseable JSON body) — _parse_tool_text / _is_error helpers already exist for this.
5. Negative-path coverage belongs in test_06_negative.py. Module-specific tests should focus on the happy path; move "not found", "bad parameter", "unauthorized" cases to the existing negative test file to avoid duplication.
6. Tool discovery smoke test. Consider adding a test_00_tool_inventory.py that calls tools/list over MCP and asserts the expected tool names are registered — this catches registration regressions in one shot.

Why it matters

• Catch REST API contract drift between dolphin-mcp-pilot and upstream DolphinScheduler releases before users hit them.
• Validate multi-tenant per-request auth (X-DS-Token, X-DS-User/X-DS-Password) across the full tool surface, not just projects.
• Give contributors confidence that refactors to client.py, middleware.py, or the ds_* helpers don't silently break tool behavior.
• Bring e2e coverage in line with the project's "53+ tools" claim in the README.

References

• Existing e2e suite: tests/e2e/
• Related: [Feature]: Add kind-based end-to-end (e2e) integration tests #8 (kind-based e2e integration tests)
• Related: [Feature]: Upgrade to MCP 2.0 and support the 2026-07-28 stateless protocol #9 (MCP 2.0 upgrade — new test files should be written against the 2.0 wire format once that lands)