View from the Ivory Tower

So, firstly, let me say that it has been a long while since my last post.  It’s been quite a year at Polaris.  A lot of good things, but enough that has kept me from blogging.  I will make a self resolution to do a better job.

One of the things that is not too well documented is what happens with the field – Associated Work Items within the test view.  I created a test for the purposes of this post called ManualTest1 as shown below:

When using the Test View you can select tests and are presented with this properties pane within Visual Studio 2008.  Notice, you can press the … button to the right and it will even give you the standard Visual Studio Work Item Query screen.  You can even choose one or multiple work items to associate with this test.

One might expect that this to manifest itself as a ‘link’ within the work item to this test definition, similarly to links to other work items or source control assets.  It is not.

It’s also not in the vsmdi file, the sln file, but where is it?

In this case, a manual test, you normally open up the test (either text or mht), you’ll notice that there is no meta data about that test visibly within the IDE.

Well, it’s actually hidden.  Open up that mht with the Source Code Editor (right click on the test in the Solution Explorer and select Open With…)

Now you’ll see where that Associated Work Item really is!

You’ll notice if you look at this file, these fields are in a commented out section of the MHT file which are not rendered in the default editor.

So – if faced with the challenge of associating “Test Cases” back to Requirements or other work items, just know that they are stored within the asset itself and if you’re use this information programmatically – get to know the Version Control APIs, be ready with some recursive programming skills, and know how to parse the embedded XML.  It’s not readily available through SSRS or typical reporting techniques in Team System 2008.

Hope this helps!