vsmdi relationship to TestCase/TestMethods
I am trying to determine how an entry inside the vsmdi file relates to a test case method.
Each test case item in a test list appears to have a unique Guid and the relative path to the assembly that the test case belongs in. However it does not list the test class that the test case belongs to.
This information is visible when viewed from the test manager, but does to appear to be stored on the filesystem.
Does anyone know how this relationship is maintained?
Answers
- vsmdi file contains information about Test Lists and tests.
- Whenever you put a Test inside a Test List there will be an entry (test list, test id) created in .vsmdi file.
- Information about disabled tests that do not belong to any Test List is also stored in vsmdi file.
- Test can be any kind of test: Unit Test, Load Test, Ordered Test, etc.
- Test id is uniquie guid that identifies the test. For Unit Tests we generate guids from (assembly, class, method) names.
- Test Manager shows this information in a tree-ogranized way.
- When Test Storage cannot be found for a test (for instance, you remove a source file outside VS IDE) Test Manager will display a Broken Link (an entry with exclamation mark). Broken Link has information about Test Storage the test was last found in.
- You can also use vsmdi file from command line to specify Test List(s) you want to run.
Thanks,
Michael - As micheal says, We maintain the relationship though a combination of test storage and Test ID -- This is because a file may contain more than one test case.
Specifically, the test storage referes to the persisted test case on disk. The TestIO is a "GUID" that refers to the specific test case -- for the Unit Test case, this test ID GUID is computed from the Assembly/Class/Method names.
This means that when we load the assembly referenced in the storage element, and then match up the test case based on some computation of the Assembly/class/method names. - To expound on Dominic's post, the reason you see the test class value in the UI is that we have loaded and parsed all of the test methods in the corresponding assembly. When a test project is loaded, we load all of the unit tests from the source files and assemblies included in the project and store them in in-memory tables. We then use those tables to populate the UI.
The test class and other metadata is not stored in the vsmdi file because it would be redundant with the information already available in the source files and assemblies. The downside of all of this is that there is no easy way for you to parse our files yourself to discover the test class corresponding to a particular test method.
All Replies
- vsmdi file contains information about Test Lists and tests.
- Whenever you put a Test inside a Test List there will be an entry (test list, test id) created in .vsmdi file.
- Information about disabled tests that do not belong to any Test List is also stored in vsmdi file.
- Test can be any kind of test: Unit Test, Load Test, Ordered Test, etc.
- Test id is uniquie guid that identifies the test. For Unit Tests we generate guids from (assembly, class, method) names.
- Test Manager shows this information in a tree-ogranized way.
- When Test Storage cannot be found for a test (for instance, you remove a source file outside VS IDE) Test Manager will display a Broken Link (an entry with exclamation mark). Broken Link has information about Test Storage the test was last found in.
- You can also use vsmdi file from command line to specify Test List(s) you want to run.
Thanks,
Michael - As micheal says, We maintain the relationship though a combination of test storage and Test ID -- This is because a file may contain more than one test case.
Specifically, the test storage referes to the persisted test case on disk. The TestIO is a "GUID" that refers to the specific test case -- for the Unit Test case, this test ID GUID is computed from the Assembly/Class/Method names.
This means that when we load the assembly referenced in the storage element, and then match up the test case based on some computation of the Assembly/class/method names. - To expound on Dominic's post, the reason you see the test class value in the UI is that we have loaded and parsed all of the test methods in the corresponding assembly. When a test project is loaded, we load all of the unit tests from the source files and assemblies included in the project and store them in in-memory tables. We then use those tables to populate the UI.
The test class and other metadata is not stored in the vsmdi file because it would be redundant with the information already available in the source files and assemblies. The downside of all of this is that there is no easy way for you to parse our files yourself to discover the test class corresponding to a particular test method. - Is the algorithm for generating these Guids available? I'd like to be able to set up entries for new tests automatically so that I can get away from the problems we have with developers forgetting to add them to the test lists.
I don't think so, although I believe it's an MD5 hash of the Full Class+TestMethod name. e.g.:
MyNamspace.SubNamspace.Class1.TestMethod1
I have not seen a public algorithm for generating the GUID's. But as Dominic indicates, it is a hash of the full class name and test method name. The earlier beta's used a MD5 hash and the release version uses a SHA1 hash.
I have a set of custom build tasks that I use to generate a test list from the unit test assembly and to generate test list files for FIT tests.
If you are interested in using the build task I have created, check out one of my old blog posts http://teamsystemrocks.com/blogs/grant_archibald/archive/2006/02/10/667.aspx where you can contact me to obtain a copy.
Yep, thats' it cracked. To summarise what is required, here's a bit of C#:
SHA1Managed
crypto = new SHA1Managed();
byte[] bytes = new byte[16];
Array.Copy(crypto.ComputeHash(Encoding.Unicode.GetBytes(className + '.' + methodName)), bytes, 16);
Guid guid = new Guid(bytes);Thanks for all the help!
- Great - this is exactly what I needed to know

Does anyone know how the id for the <TestList> element is generated? I tried hashing just the name of the test list (e.g. MyTestList) but I get
d8f1e2c5-3659-b2f4-ade1-fa977b334d01
instead of:
dbe82f10-a3a6-4b13-99af-f5bf5c5a7923
Do I need to prefix MyTestList with something? Apparently, the id of the lists are not generated with the name of the list.
You could used Guid
.NewGuid() to generate them.Except for the main list (List of Tests) that have always the same id.


