TFS服务器的Web界面定义？

我正在C项目中使用TFS2010服务器。为了与之交互，我使用本机C代码，如下所示：

    WorkItemStore WiStore = 
        TfsTeamProjectCollectionFactory.
        GetTeamProjectCollection(new Uri("http://mgtfsweb01:8080/tfs")).
        GetService<WorkItemStore>();    
    String queryStr = "Select * from Issue where (ID = " + issue + ")";
    WorkItemCollection witCollection = WiStore.Query(queryStr);

---

这个很好用。但是，我想测试这个函数。为此，我不想将它指向我们的生产服务器。相反，我想要一个临时的假服务器来响应WiStore.Query调用。为了实现这一点，我想了解一下TFS2010的HTTP接口的定义。有人知道这些信息是否在任何地方发布吗？

测试代码的最快、最可靠的方法是安装TFS服务器

只需设置一个VM，并在单个服务器配置中安装它。TFS2010非常容易启动和运行

---

模拟接口当然有一定的吸引力，但由于各种依赖关系，您将不可避免地陷入兔子洞。

要直接回答您的问题，是的，您可以在最后获得各种web服务方向的WSDL。然而，曾经有幸为商业产品逆向工程TFS web服务，我不得不建议您不要这样做

正如Chris Lively所说的，只需使用伪数据运行测试TFS服务器将更容易。这就是微软测试客户机的方式——我们做梦也想不到会嘲笑web服务，尤其是工作项跟踪web服务，因为它非常复杂。为什么?

与工作项跟踪web服务交谈的第一步是交换工作项跟踪元数据。其中包含流程模板，即关于所有工作项类型bug、测试用例、任务等的信息，包括所有字段、各种TFS客户端在屏幕上呈现的方式、根据另一个字段的内容更新一个字段时发生的触发器，字段的可能内容包括区域列表、迭代、可能是Assigned To字段中有效值的用户等。此模式不公开，也不容易进行反向工程，如果没有此模式，工作项跟踪客户端将无法运行。任何工作项跟踪事务的第一步是确保客户机的元数据表与服务器的元数据表是最新的

这将是非常困难的消费。创造它将更加困难。我认为您可以使用生产服务器中的现有元数据表

不过，一旦跳过了这一障碍，处理工作项查询就不算太糟糕了。构建存储查询的查询层次结构是相当容易的，但是您需要确保您的模拟查询是正确的WIQL，因为客户端应该在尝试执行查询之前对其进行解析并进行健全性检查。如您的示例所示，如果您只想通过ID获取单个工作项，那么这将是相当简单的

理论上，您可以构建假工作项来响应查询。但是，客户端维护一个规则引擎，以确保工作项处于有效状态。也就是说，bug不能有激活状态和修复原因。因此，您希望确保构建的模拟工作项符合流程模板中工作项的规则

但在某一点上，你的测试实际上在测试什么？他们是在测试您正在编写的客户端代码，还是在测试您构建的模拟TFS服务器

最后，Microsoft不支持直接与web服务对话。这些接口在未来可能会发生巨大的变化，如果您有疑问，党的路线答案可能是我们不支持这一点。也许我已经说得太多了

另请参见：这实际上涉及到构建新客户机，而不是模拟服务器

---

如果您还不确定，可以通过查看IIS配置来获取各种web服务的WSDL。例如，您应该看到WorkItemClient.aspx。如果将查询字符串？wsdl附加到该字符串的末尾，则可以获取工作项跟踪客户端的wsdl。Fiddler和Wireshark将成为您的好朋友。

是的，但这是单元测试的一部分，我希望它能够在使用VS2010的任何机器上运行。它应该支持并发操作，所以理想情况下，我希望每个单元测试实例都有一个不同的TFS测试实例。因此，我不能要求每个开发人员在自己的工作站上安装TFS。@StephenGross:实际上，我们有一个专用的TFS测试服务器，每个版本的TFS服务器都有一个，具有不同的项目集合和团队项目。你可以给每个开发人员自己的团队项目，或者——为了更隔离——给他们自己的项目集合。哇，你真的吓到我了。@StephenGross:如果我不说这很有趣的话，我是在撒谎