Audit and refactor unit tests to use new Client class #1891

Activity

1. felixweinberger

   self-assigned this

   on Jan 16, 2026
2. felixweinberger

   added

   v2Affects the v2 line (2.x on main)Affects the v2 line (2.x on main)

   enhancementRequest for a new feature that's not currently supportedRequest for a new feature that's not currently supported

   P1Significant bug affecting many users, highly requested featureSignificant bug affecting many users, highly requested feature

   on Jan 16, 2026
3. felixweinberger

   added a commit that references this issue on Jan 16, 2026

   refactor: use Client class in tests

   ...

   dde19fb
4. peytongreen-dev commented on Mar 30, 2026

   

   peytongreen-dev

   on Mar 30, 2026

   More actions

   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
5. Kludex commented on Apr 5, 2026

   

   Kludex

   on Apr 5, 2026

   Member

   More actions

   @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.
6. claude commented on Apr 5, 2026

   

   claudebot

   on Apr 5, 2026 – with Claude

   Last edited by claude

   Contributor

   More actions

   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).

   ---
7. Kludex

   closed this as completedon Apr 5, 2026