I've been wondering if the Build Artifact Moniker really is the linking item or not. I have now confirmed that it really is so. As we got the tip from Mr. König to look at hos Test Results are published, I decided to try it out. I created a new project (under my newly created Team Project - keep in mind the difference between Project and Team Project!), and generated some unit tests for the project by using the built-in wizard in Visual Studio. 2 tests were created. I ran the tests by choosing Test --> Run --> All tests in Solution...

Next up was to click the Publish button in the Test Results view that appears at the bottom. See the picture below (I didn't care to implement the tests - I just wanted tests to run, never mind that they don't pass!)

...which takes you to the next screen, where the interesting stuff starts to happen:

As you can see, you have to associate a build to your published test results. The text showing in the drop-down menu above is exactly the same as the one found in [dbo].[TfsWarehouse].[Build].[Build] field. (TfsWarehouse is the database, the first Build is the table, and the last Build is the column in the table). "Behind the scenes" the Build Artifact Moniker is hiding, mapped to each of these builds. How do I know that? Well, I had to do some experimentation. Here's how I did it.

As in the picture above, I chose to associate build number "XjobBuild_20071203.1" to the test results. Keep in mind that I had not published any test results before, so the Test results table in the warehouse was empty.

A sidenote: The Build names are generated automatically by the system to follow the standard of:

[Name-of-build-type]_[date-when-build-is-created].[version-number]. version-number starts with 1 for the first build, and is incremented +1 every time you make a new build of the same type (on the same date).

When I had published the test results, I ran this query in Microsoft SQl Server Management Studio Express (auto-generated by right-clicking on the [TfsWarehouse].[dbo].[Test Result] table and choosing Script Table as --> SELECT To --> New Query Editor Window. I know I didn't have to choose all elements, but it was faster than manually typing the statement ;-) )

SELECT [__ID]
      ,[Result Record Count]
      ,[Result Count]
      ,[Result Transition Count]
      ,[__LastUpdatedTime]
      ,[__LastUpdatedBy]
      ,[__TrackingId]
      ,[Result]
      ,[Build]
      ,[Run]
      ,[Area]
      ,[Iteration]
      ,[Date]
      ,[Outcome]
      ,[Finished Date]
      ,[Agent Machine]
      ,[Category]
      ,[Owner]
      ,[Run By]
      ,[Platform]
      ,[Flavor]
      ,[Team Project]
  FROM [TfsWarehouse].[dbo].[Test Result]

Among the results I got, I could see that Build Artifact Moniker == 7. So I ran this query on the the [TfsWarehouse].[dbo].[Build] table, in the same way as above:

SELECT [__ID]
      ,[Build Artifact Moniker]
      ,[Build]
      ,[Build Type]
      ,[Drop Location]
      ,[Build Start Time]
      ,[__LastUpdatedTime]
      ,[__DimensionMemberActive]
  FROM [TfsWarehouse].[dbo].[Build]

And voila. In the table there is a row which has Build Artifact Moniker == 7, and the build name is - exactly as predicted - XjobBuild_20071203.1. It resides on the drop location \\ORCASBETA2_TFSV\share\XjobBuild_20071203.1.

Conclusion: Build Artifact Moniker (B.A.M) is definitely the key identifier we should use to map our code metrics to a specific Build. Note that the B.A.M is a number, but the datatype in the SQL database is nvarchar(64) - it is not an int (!)