What typically happens is that VS2005 automatically checks-out the metadata file even when a developer do not work on a unit test, or touch the test project or the test manager. As the check-out is silent, the developer does not notice this. After doing some coding, the developer will try to check in the pending changes. In the meantime, other developers will also have done some unit tests, coding and check-ins, causing a conflict on the .VSMDI file. At this point, VSMDI is a disaster waiting to happen...
Never ever use 'auto merge' to resolve check-in conflicts on the .VSMDI file. The chances are that the file will get corrupted. If you have a conflict, I recommend discarding your local changes, get the latest version of the .VSMDI file from TFVC (use 'force get...' and 'overwrite...' if necessary), then re-apply your changes to the tests and test lists, and check the file in immediately. Do not keep the .VSMDI file checked out longer than strictly necessary.
A sure sign of a corrupted VSMDI file is a Test Manager that never stops loading, the progress bar teasing you at "almost there" forever.
[UPDATE] I recommend that you reconfigure the .VSMDI file TFVC settings to not allow merging or multiple check-out. This is done in the 'Edit File Type' (see image above), which is available at 'Team-Team Foundation Server Settings-Source Control File Types' in VSTS.
VSTS will also check-out .VSMDI even when doing a get latest on the whole solution. I recommend my developers to immediately do a 'undo pending changes' on the file when this happens. The check-out seems to be quite unnecessary, why can't VSTS leave the file as-is until I touch the test system ? I know that VSTS monitors the disk for changes to relevant files, but I would prefer that the test metadata only got updated when building the solution.
Due to the VSTS test system's unreliable handling of the metadata file, we from time to time get "The test 'TestName' does not exist in the test list. It may have been moved, renamed or deleted". Yesterday, the 'Test Manager' showed all tests duplicated in the test lists. Today, another developer saw just some chinese characters when opening the metadata file. Sometimes we even get a second VSMDI file (e.g. Application2.vsmdi) in our solution, or no VSMDI file at all.
Some of my Objectware co-workers have given up TFS for unit testing due to this, and are using NUnit and CruiseControl.NET in their projects instead.
6 comments:
Yes, we are experiencing this too. Our SCC provider (PVCS, ugh!) does not allow multiple checkouts, so somehow we have been getting additional VSMDI files included in the solution. It would be nice to not have the option of having a local, non-source-controlled VSMDI file.
So we're not the only ones! Why aren't more folks having problems with this? Perhaps they're just not complaining about it? I'd be curious if anyone has a workaround. I've posted to the MSDN Forums about this, so we'll see what happens.
Same here. We have several townsend test cases and pretty large test lists hierachy and this is really frustrating. I've also posted the issue in the VSTF forum, but I have not seen a workaround or best practice so far... Thanks for the tip.
Here is a work-around that seems to work -
1. Make sure Visual Studio is NOT set up to load the last-used solution file automatically (Tools -> Options, open Environment->Startup and make sure it does not say 'At startup: Load last loaded Solution'.
2. When you open a solution, make sure the Test View and Test Results windows are CLOSED. It seems that having these windows open when opening a solution causes the auto-checkout to occur.
3. Lastly, when you get the latest version of a solution, again make sure the Test View and Test Results windows are CLOSED. Same deal as above.
Thank you!
We have been having a lot of problems with those files. I am hoping this will work.
http://www.marcusoft.net/2008/03/how-to-get-rid-of-multiple-vsmdi-files.html
I think I have found a simple solution to this problem.
Do NOT put the .vsmdi file into source control.
In my tests, anyway, it is rebuilt from stratch whenever I RUN the Unit Tests.
-Jesse Chisholm
Post a Comment