我想对我的 Web API 控制器进行集成测试。 当集成测试开始时，应处理 Web API 的整个请求/响应管道，使其成为真正的集成测试。
我阅读了一些关于非 InMemory 测试或 InMemory 测试的博客。我需要知道有什么区别，哪些方法符合我的上述标准？
我真的很高兴看到那些真正处理自托管或 IIS 托管的 Web API 集成测试的人的一些解释（如果测试存在差异......）
【问题讨论】：
标签： asp.net-web-api integration-testing asp.net-web-api2
不确定您所说的非内存测试是什么意思，但是对于涉及内存托管 Web API 的集成测试，请求会直接发送到HttpServer，这基本上是在 ASP 中运行的第一个组件。 NET Web API 管道。这意味着，请求不会命中网络堆栈。因此，您无需担心在特定端口上运行等问题，而且如果您编写了大量测试，运行所有测试所需的时间不会太大，因为您处理的是内存而不是网络。您应该获得与典型单元测试相当的运行时间。查看来自 Kiran 的出色 post，了解有关内存测试的更多详细信息。内存中测试将运行您设置为在管道中运行的所有组件，但需要注意的一件事是格式化程序。如果您在请求中发送ObjectContent，则无需运行媒体格式化程序，因为请求已经是反序列化格式，因此不会发生媒体格式化。
如果您想更接近并愿意在运行时间上受到影响，您可以使用自托管来编写测试。这就是非内存测试的意思吗？例如，您可以使用 OWIN 自托管。您可以使用 Katana 托管 API 并托管您的 Web API 并根据您的请求进行访问。当然，这将使用真正的 HttpListener 并且请求确实会遍历网络堆栈，尽管这一切都发生在同一台机器上。测试会相对较慢，但您可能会更接近您的产品运行。
我个人还没有看到任何人使用网络托管并进行大量集成测试。从技术上讲，可以使用HttpClient 触发您的请求并检查响应和断言内容，但您无法控制以编程方式安排测试。
我的选择是混搭，也就是尽可能使用内存测试，只在需要真正上网的特定情况下才使用基于 Katana 的主机。
【讨论】：