Кто-нибудь на самом деле успешно использует MSTest в команде?

Question

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

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

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

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

РЕДАКТИРОВАТЬ: Благодаря ответам в этой теме я подтвердил, что MSTest работает для моих целей и изящно интегрирован с инструментами CI и серверами сборки.

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

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

Answer 1

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

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

По крайней мере, с TFS MSTest прекрасно работает как часть нашего CI.

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

Если вы оцениваете фиктивные библиотеки, взгляните на это сравнение .

Answer 2

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

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

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

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

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

Answer 3

Я использую 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 на вашем сервере сборки, если вы используете, например, Круиз-контроль .NET. См. этот вопрос переполнения стека для деталей.

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

Answer 4

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