2009-12-22 4 views
4

Я использую MSTest до сих пор для своих модульных тестов и обнаружил, что иногда это случайным образом разбивает мои сборки без причины. Сборка будет неудачной в VS, но скомпилировать ее в MSBuild - с ошибкой, такой как «option strict», не позволяет IFoo использовать тип IFoo. Я верю, что, наконец, исправил его, но после того, как ошибка вернулась и изо всех сил пыталась заставить ее уйти снова и небольшая помощь от MS, у меня остался плохой вкус во рту. Я также заметил, что, глядя на этот форум и другие блоги и такие, что большинство людей используют NUnit, xUnit или MBUnit .. Мы на VS2008 на работе BTW .. Так что теперь я ищу, чтобы изучить другие варианты.Кто-нибудь действительно успешно использует MSTest по всей команде?

Я работаю над тем, чтобы переместить нашу команду, чтобы начать делать TDD и реальное модульное тестирование и планировать некоторые тренировки, но сначала хотел бы предложить набор стандартных инструментов & лучших практик. С этой целью я искал онлайн, чтобы найти подходящую инфраструктуру как для сервера сборки, так и для dev-машин ... Я смотрел на веб-сайт typemock, так как я слышал о своих смешных фреймах и замечал, что это похоже, что они продвигают MSTest и даже имеют некоторые ссылки людей, перемещающихся TO MSTest from NUnit ..

Это заставляет меня переосмыслить мое решение .. поэтому, я думаю, я спрашиваю: кто-нибудь использует MSTest как часть своей инфраструктуры TDD ? Любые известные ограничения, которые у него есть, если я хочу интегрироваться со сборщиком/CI-сервером или охватом кода или любым другим типом TDD-инструмента, который мне может понадобиться? Я искал эти форумы и в основном обнаружил, что люди сравнивают сторонние структуры с каждой из сторон и даже не дают MSTest большую часть шанса ... Есть ли веская причина, почему ...?

Спасибо за совет

EDIT: Благодаря ответам в этой теме, я подтвердил MSTest работает для моих целей и integreated грациозно CI инструментов и создания серверов.

Но есть ли у кого-нибудь опыт работы с FinalBuilder ?? Это инструмент, который я бы хотел использовать для скриптов сборки, чтобы не писать тонну XML по сравнению с другими инструментами построения. Какие-либо ограничения здесь, о которых я должен знать, прежде чем перейти к тестированию MS?

Следует также отметить, - мы используем VSS = (я надеюсь, что мы можем топор это в ближайшее время. -., Надеюсь, как часть, может быть, даже на первом этапе, в создании всего этой инфраструктуры

ответ

2

В Safewhere мы в настоящее время используем MSTest для TDD, и она работает нормально.

Лично я люблю интеграцию IDE, но не нравится API. Если когда-нибудь станет возможным интегрировать xUnit.NET с испытательным бегуном VS, мы будем мигрировать очень скоро после этого.

A t наименее с TFS, MSTest работает очень хорошо, как часть нашего CI.

В целом я считаю, что MSTest работает для меня адекватно, но я не цепляюсь за него.

Если вы оцениваете библиотеки-макеты, взгляните на this comparison.

+0

Согласно 9-му каналу, MSTest в VS2010 позволит вам интегрировать другие тестовые среды в графический интерфейс GUI. Должно быть здорово! – Finglas

+0

Спасибо за примечание. @Mark - любая идея ограничения использования MSTest/TeamCity с версией VS2008 Dev? Я беспокоюсь, что это может быть ограничено, поскольку мы не на TFS ... И что вы используете для своих скриптов сборки? Я надеялся использовать FinalBuilder, и я надеюсь, что он отлично справится с MSTest/VS2008 Dev .. – dferraro

+0

Ранее мы использовали TeamCity и ограничение с тем, что нет встроенной поддержки MSTest, поэтому вам придется запрограммировать собственную задачу MSBuild, которая выполняет тестовые пакеты. –

1

Я использую MS Test, так как VS 2008 вышел, но мне не удалось проделать что-либо вроде TDD или CI здесь на работе, хотя я немного поработал с Cruise Control в попытке постройте сервер CI в моем локальном поле.

В целом, я нашел MS Test достаточно хорошим для тестирования на местном уровне, но есть некоторые болевые точки для институционального использования.

Во-первых, MS Test добавляет немало вещей, которые, вероятно, не принадлежат источнику контроля. Файлы .VSMDI особенно раздражают; просто запуск MS Test создает от 1 до 5 из них и добавляет их в файл решения. Это означает, что вы отказываетесь от своего .SLN в контроле источника, а оттока такого рода плоха.

Я понимаю предполагаемый момент за этими дополнительными файлами - отслеживание истории запуска и т. Д. - но я не считаю их особенно полезными ни для чего, кроме одного разработчика. Вы должны использовать свой сервис сборки и CI для такого рода вещей!

Во-вторых, вы либо должны иметь Team Foundation Server для запуска ваших модульных тестов как часть CI, либо вы должны иметь копию Visual Studio, установленную на вашем сервере сборки, если вы используете, например, Cruise Control. СЕТЬ. См. this Stack Overflow question.

В общем, в MS Test нет ничего плохого. Но переход CI будет не таким гладким, как может быть.

1

Я очень успешно использовал MSTest в нашей компании. В настоящее время мы создаем стандартизированные процессы сборки в нашей компании, и до сих пор у нас был хороший успех с TeamCity. Для непрерывной интеграции мы используем конфигурации TeamCity. Для реальных релизов мы создаем большие скрипты msbuild, которые автоматизируют весь процесс.

Мне очень нравится mstest из-за интеграции IDE, а также что все наши разработчики автоматически могут использовать его без установки каких-либо зависимостей сторонних разработчиков. Я бы не рекомендовал переключение только из-за проблемы, с которой вы столкнулись. Я пришел полным кругом, где мы подошли к nunit, а затем снова вернулись. В конце концов, эти рамки все равно одинаковы, поэтому выбирайте тот, который проще всего для большинства ваших разработчиков, чтобы получить доступ и начать использовать.

Что я подозреваю, что ваша проблема может быть ... звучит как неясная проблема, с которой я столкнулся раньше, где некорректные ссылки на dll (например: добавление явных ссылок (через просмотр) к проектам в вашем решении, а не использование ссылки на проект) приводит к устаревшим проблемам, которые возникают только после чистых проверок или сборок.

Другой действительно подозрительный вопрос, который я нашел раньше, - это если у вас есть визуальный компонент или элемент управления, который имеет общедоступное свойство некоторого настраиваемого типа, которое сериализуется в файле .resx. Мне обычно нужно отметить их атрибутом, который говорит SerializationVisibility.Hidden. Это означает, что среда IDE не будет пытаться создавать сеттеры для значения свойства (которое обычно является некоторым графом объектов). Просто мысль. Может быть выход.

Я доверяю инструментам, и они действительно не лгут о том, что есть настоящая проблема. Они только искажают их или сообщают о них как о чем-то совершенно неясном. Это звучит так, как будто у вас есть это. Я подозреваю это, потому что сообщение об ошибке не имеет смысла, если все в порядке, но имеет смысл, если какая-то часть кода загрузила устаревшую или измененную версию DLL в этот момент.

+0

Благодарим за то, что CI и серверы сборки отлично работают с MSTest. Почему вы используете скрипты ms build, если у вас есть TeamCity? А как насчет FinalBuilder - вы заглянули в него? Это инструмент высокого уровня, который заменяет nAnt/Ant/MSBuild и устраняет необходимость в сложных/трудоемких вручную созданных сценариях. Или FinalBuilder не хорошо работает с MSTest? Может ли кто-нибудь подтвердить, что он хорошо играет с ним, или если у вас есть некоторые проблемы, и если да, то как ограничивать? Я планировал использовать FinalBuilder - я также отредактирую свое оригинальное сообщение, чтобы включить этот вопрос. Еще раз спасибо за помощь – dferraro

+0

Ох - и это очень важно - вы используете VS2008 ?? Поскольку у нас нет роскоши Team Foundation - и сомневаюсь, что это возможно для бюджета ... – dferraro

0

Я успешно развернул несколько установок FinalBuilder, и клиенты были очень довольны результатом. Я могу очень порекомендовать его.

Смежные вопросы