TFS 服务器的 Web 界面定义? [英] Web interface definition for TFS server?

问题描述

我正在 C# 项目中使用 TFS2010 服务器.为了与它交互，我使用了原生 C# 代码，如下所示:

I'm working with a TFS2010 server in a C# project. To interact with it, I'm using native C# code like so:

    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 接口定义是什么.有谁知道此信息是否在任何地方发布?

This works fine. However, I would like to test this function. To do so, I don't want to point it to our production server. Instead, I'd like a temporary fake server to provide responses to the WiStore.Query() call. To accomplish this, I'd like to find out what the definition of the HTTP interface is for TFS2010. Does anyone know if this information is published anywhere?

推荐答案

直接回答你的问题，是的，你可以得到各种 Web 服务的 WSDL(方向在最后.)但是，曾经有幸对 TFS Web 服务进行逆向工程(对于商业产品，而不是指向测试)我不得不建议您不要这样做.

To answer your question directly, yes, you can get the WSDL for the various web services (directions at the end.) However, having once had the pleasure of reverse engineering the TFS web services (for a commercial product, not to point tests at) I'd have to suggest that you not do this.

正如 Chris Lively 所说，使用假数据运行测试 TFS 服务器会容易几个数量级.这就是 Microsoft 测试他们的客户的方式——我们做梦也想不到要模拟 Web 服务，特别是，因为工作项跟踪 Web 服务非常复杂.为什么?

As Chris Lively stated, it will be orders of magnitude easier to just run a test TFS server with fake data instead. This is how Microsoft tests their clients -- we would never dream of mocking the web services, especially the work item tracking web service due to the sheer complexity. Why?

与工作项跟踪 Web 服务对话的第一步是交换工作项跟踪元数据.这包含流程模板 - 即，有关所有工作项类型(错误、测试用例、任务等)的信息，包括所有字段、它们应为各种 TFS 客户端呈现在屏幕上的方式、触发发生基于另一个字段的内容和字段的可能内容(区域列表、迭代、可能是分配给"字段中的有效值的用户等)更新一个字段的模式.不公开且不容易进行逆向工程，如果没有这个，工作项跟踪客户端将无法运行.(任何工作项跟踪事务的第一步都是确保客户端的元数据表与服务器的元数据表保持同步.)

The first step in talking to the work item tracking web service is exchanging the work item tracking metadata. This contains the process templates - that is, information about all the work item types (bug, test case, task, etc.) including all the fields, the way they should be rendered on-screen for the various TFS clients, the triggers that occur to update one field based on the contents of another field, and the possible contents of the fields (a list of areas, iterations, users that could possibly be valid values in the "Assigned To" field, etc.) The schema for this is not public and not easy to reverse engineer, and without this, the work item tracking client will fail to function. (The first step in any work item tracking transaction is to ensure that the client's metadata table is up-to-date with the server's.)

吃这个会很困难.创建它会更加困难.(我想您可以使用生产服务器中的现有元数据表.)

It would be very difficult to consume this. It would be even harder to create it. (I suppose it's possible that you could use an existing metadata table from your production server.)

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

Once you've jumped this hurdle, though, dealing with work item queries is not too bad. It's fairly easy to build a query hierarchy of stored queries, however you'll need to ensure that your mock queries are proper WIQL, as the client should parse it and sanity check it before trying to execute a query. If, as in your example, you only want to get a single work item by ID then that would be fairly straightforward.

理论上，您可以构建虚假的工作项来响应查询.但是，客户端维护一个规则引擎"以确保工作项处于有效状态.(即，错误不能具有状态活动"和原因已修复".)因此，您需要确保构建的模拟工作项符合流程模板中工作项的规则.

You could, in theory, be able to build fake work items in response to a query. However, the client maintains a "rules engine" to ensure that the work item is in a valid state. (Ie, a bug cannot have state "Active" and reason "fixed".) So you'd want to ensure that you were building mock work items that complied with the work item's rules in the process template.

但在某些时候，您的测试实际测试的是什么?他们是在测试您正在编写的客户端代码，还是在测试您构建的模拟 TFS 服务器?

But at some point, what are your tests actually testing? Are they testing the client code you're writing, or are they testing the mock TFS server you've built?

最后，Microsoft 不提供直接与 Web 服务对话的支持.这些界面在未来可能会发生巨大的变化，如果您有任何疑问，当事人的回答可能是我们不支持那个".(也许我已经说得太多了！)

Finally, Microsoft does not provide support for talking directly to the web services. These interfaces may change drastically in the future, and should you have questions, the party-line answer will likely be "we don't support that." (Perhaps I've already said too much!)

另见:"是否有关于 TFS Web 服务的文档?" 真正关心的是构建一个新的客户端，而不是模拟服务器.

Also see: "Is there any documentation on TFS Web Services?" which really concerns building a new client, not mocking the server.

如果您还不太相信，您可以通过查看 IIS 配置来获取各种 Web 服务的 WSDL.例如，您应该看到 WorkItemClient.aspx.如果您将查询字符串 ?wsdl 附加到它的末尾，您将能够获得工作项跟踪客户端的 WSDL.Fiddler 和 Wireshark 将成为您的好朋友.

If you're not suitably convinced yet, you can get the WSDL for the various web services by looking at the IIS configuration. You should see, for example, WorkItemClient.aspx. If you append the query string ?wsdl to the end of that, you'll be able to get the WSDL for the work item tracking client. Fiddler and Wireshark will become your very good friends.

这篇关于TFS 服务器的 Web 界面定义?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！