Description
Originally posted by @PederHP in PederHP/mcpdotnet#62.
#51 merged ClientIntegrationTests and ServerIntegrationTests as both instantiate a client in test code.
However the previous ServerIntegrationTests do test the McpServer code via the TestServer project, so I am starting to wonder if it was right to merge them. I also have SseServerIntegrationTests on the SSE server support branch. The point of these test classes is to integration test the server, by using client code that is integration tested against the reference server and hence can be assumed to work correctly.
Integration tests can be heavy duty / awkward (as can be seen by the use of a containerized everything server instead of the npx based one), but I still think they're very important due to the nature of MCP. I think it would make sense to organize IntegrationTests based on whether they are meant exercise client, server or both.
When Authorization feature is implemented, I suspect a separate suite for that will be relevant, as Authorization flow is relatively complex with PKCE, etc. This is a feature still in active development by the MCP maintainers, so it might change, but however it ends up looking I expect it will need a fair amount of integration test code.