Почему Visual Studio создает новый файл .vsmdi?
Если я открываю решение в Visual Studio 2008 и запускаю модульный тест, VS создает новый файл .vsmdi в папке Solution Items и дает ему следующий доступный номер, например. Мое решение2.vsmdi.
Есть идеи, почему VS делает это и как я могу заставить его перестать это делать?
Ответы 4
старый пост, но vsmdi - это файл метаданных, созданный тестовой системой.
Похоже, что Проблема VSMDI - это известная ошибка, которая существует с VS2005 Team System., но пока нет четкого исправления. Еще одна причина НЕ использовать MS Test.
Подробная информация о как запускать модульные тесты без файлов VSMDI в блоге MSDN.
первая ссылка была недоступна в то время, когда я щелкнул по ней, но вы можете прочитать ее в архиве благодаря The Wayback Machine: web.archive.org/web/20080302162715/http://…
@ Jon Limjap: вы написали «Еще одна причина НЕ использовать MSTest». Мне любопытно: каковы еще ваши причины НЕ использовать MSTest? Кроме того, какие фреймворки для модульного тестирования вы предпочитаете? Кстати: странно, я получаю ошибку .vsmdi, но тесты, похоже, запускаются независимо от того, что слишком странно для моих предпочтений. С уважением ~~ gerry (lowry) [email protected]
Джерри, вы должны принять к сведению, что это очень старый ответ. В то время MSTEst был относительной новинкой в сфере разработки, основанной на тестировании. Этого следовало избегать, потому что его было трудно использовать: для облегчения тестирования необходимо было создать прокси-класс между реальными объектами. Это очень сильно отличается от инструментов на основе NUnit и NUnit (MbUnit, xUnit и т.д.), которые в то время были достаточно зрелыми в качестве фреймворков для модульного тестирования с открытым исходным кодом. До сих пор я предпочитаю MbUnit.
Джон, спасибо за объяснение. Вы смотрели xUnit.net? Джим Ньюкирк (автор NUnit 2) и Брэд Уилсон создали xUnit.net [xunit.codeplex.com/]. Даниэль Каззулино (автор Moq) использует xUnit.net для тестирования Moq. Почему вы предпочитаете MbUnit?
Джерри, на самом деле я предпочитаю не столько предпочтение, сколько зону комфорта - мы использовали его в долгом проекте, используя насмешки Rhino в качестве насмешки. На днях я могу попробовать xUnit и Moq, и, возможно, это изменит мое мнение. Давайте посмотрим. :)
Привет, ребята, на самом деле вам не нужен прокси-объект для взаимодействия с тестируемыми классами в MSTest. Вы могли бы сделать это предположение, если бы использовали его ненадолго. Я почти никогда не использую эти вспомогательные классы и генерирую заглушки и не пишу тесты в MSTest, как любой другой, работающий с NUnit. Это просто вопрос предпочтения.
Я работаю над этим, всегда проверяя .vsmdi.
Похоже, это происходит только тогда, когда файл .vsmdi доступен только для чтения, например. не проверено в системе контроля версий, которая использует такое поведение блокировки локальных файлов (Perforce и т. д.).
Предполагая, что файл VSMDI находится под контролем источника, вот статья службы поддержки Microsoft об этой проблеме: Несколько файлов vsmdi после запуска командного теста с файлом VSMDI в системе управления версиями
Что говорит:
Кто-то провел тест, пока кто-то изменял файл vsmdi. Team Test обнаруживает, что файл VSMDI не синхронизирован; поэтому Team Протестируйте его, и вы увидите увеличивающиеся файлы vsmdi.
И:
В дальнейшем вы хотите убедиться, что файл не помечен для автоматического оформить заказ при его изменении. Когда текущий тестер имеет VSMDI файл проверил вас, не хочу, чтобы другие пользователи могли его проверять из. Вы хотите, чтобы ваши разработчики проверили файл, запустили тест и проверьте это снова.
Возможный дубликат какова цель * .vsmdi? Нужен ли мне исходный контроль?