问题
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);
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?
回答1:
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.
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?
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.)
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.
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?
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!)
Also see: "Is there any documentation on TFS Web Services?" which really concerns building a new client, not mocking the server.
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.
回答2:
The fastest, and most reliable, way to get to testing your code is going to be to install a TFS server.
Just set up a VM and install it in a single server configuration. TFS 2010 is pretty easy to get up and running.
Mocking the interface certainly has some allure but you will inevitably be drawn into a rabbit hole due to various dependencies.
来源：https://stackoverflow.com/questions/9132139/web-interface-definition-for-tfs-server