Audit and refactor unit tests to use new Client class

[felixweinberger]

Audit existing unit tests and refactor as much as possible to use the new Client class instead of the older patterns.

Follow-up from #1870.

[peytongreen-dev]

Related: I just published mcp-testclient (https://pypi.org/project/mcp-testclient/) which provides a pytest-native TestClient for the low-level Server class.

It uses anyio memory streams to wire a Server directly to a ClientSession — no subprocess, no HTTP, no stdio. Might be useful context for the refactor direction here:

from mcp_testclient import TestClient

def test_my_server():
    with TestClient(server) as client:
        result = client.call_tool("my_tool", {"arg": "value"})
        assert result[0].text == "expected"

Repo: https://github.com/peytongreen-dev/mcp-testclient

[Kludex]

@claude can you check what tests can move to use Client, as mentioned by the OP? Please apply the suggestion in case of simplification, if the test becomes more complicated, do not use Client.

[claude]

Claude finished @Kludex's task in 2m 54s —— View job

---

Audit complete: Tests already optimally use Client class ✓

• Understand the new Client class pattern by reading reference test file
• Audit existing test files to identify candidates for refactoring
• Assess which tests would be simplified by using Client
• Refactor tests to use Client where it simplifies them
• Run tests to verify changes
• Push changes to branch

Summary

After a comprehensive audit of the test suite, I found that the codebase is already in excellent shape - tests are using Client where appropriate, and tests using ClientSession directly are doing so for valid technical reasons.

Tests already using Client (following best practices)

These tests correctly use the high-level Client class for E2E testing:

• ✅ tests/client/test_client.py - Reference implementation
• ✅ tests/client/test_sampling_callback.py
• ✅ tests/client/test_list_roots_callback.py
• ✅ tests/client/test_logging_callback.py
• ✅ tests/server/mcpserver/test_integration.py
• ✅ tests/server/mcpserver/test_elicitation.py
• ✅ tests/server/mcpserver/test_url_elicitation.py
• ✅ tests/server/mcpserver/test_server.py
• ✅ tests/server/lowlevel/test_server_listing.py
• ✅ tests/shared/test_progress_notifications.py (2nd test uses Client)

Tests correctly using ClientSession directly

These tests appropriately use ClientSession for testing low-level functionality:

Transport-specific tests:

• tests/client/test_session.py - Testing ClientSession internals
• tests/client/test_stdio.py - Testing stdio transport layer
• tests/client/test_http_unicode.py - Testing HTTP Unicode handling
• tests/client/test_notification_response.py - Testing HTTP error handling
• tests/shared/test_streamable_http.py - Testing HTTP transport internals
• tests/shared/test_sse.py - Testing SSE transport
• tests/shared/test_ws.py - Testing WebSocket transport

Low-level session tests:

• tests/shared/test_progress_notifications.py (1st test) - Bidirectional progress with manual stream control
• tests/issues/test_88_random_error.py - Testing timeout/session edge cases
• tests/server/test_session.py - Server session internals
• tests/server/test_cancel_handling.py - Cancellation handling
• tests/server/test_* (various) - Low-level server behavior

Experimental features:

• tests/experimental/tasks/client/test_handlers.py - Task handler internals
• tests/experimental/tasks/test_elicitation_scenarios.py - Task integration scenarios

Other valid reasons:

• tests/client/test_session_group.py - Testing ClientSessionGroup (different abstraction)
• tests/issues/test_scope_bug_1630.py - OAuth authentication (no MCP client/server)
• tests/issues/test_100_tool_listing.py - Direct server testing (no client needed)

Conclusion

No refactoring needed. The test suite already follows the guidance from CLAUDE.md:

"Be minimal, and focus on E2E tests: Use the mcp.client.Client whenever possible."

The tests using Client do so for E2E testing, while tests using ClientSession directly are appropriately testing:

1. Transport layer implementations
2. Low-level session behaviors
3. Error handling and edge cases
4. Experimental features
5. Internal mechanisms that require precise control

The codebase demonstrates good separation of concerns between high-level E2E tests (using Client) and low-level unit tests (using ClientSession).

---