Microsoft выпускает кучу библиотек и тулов, покрывающих все аспекты разработки, но иногда это незрелые решения. Есть мнение, что зачастую в Microsoft пишут продукты «чтобы было» а не «чтобы сделать что-то полезное».

Вот как Scott Bellware (Microsoft MVP) объясняет, почему он не использует MsTest (спасибо за перевод, Alexander):

Лично я не использую MS Test. Этот продукт был создан людьми, которые весьма далеки от реальной практики тестирования. MS Test привлекает неопытных людей своим визуальным оформлением, людей, которые покупают вещи за их внешнюю красоту и глянец. VSTS довольно далека от современных cross-functional roles, которые все чаще используются разработчиками. Банальная переплата денег.

Создание расширений для MS Test - бесполезное занятие. Небольшое сообщество людей, которые занимались этим делом, по большей части следует рекомендациям Microsoft по тестированию, что означает следующее: они упускают из вида так называемую разработку, движимую поведением (BDD), в той же степени, в которой Microsoft упускает из вида TDD. В этой области мир открытого кода развивается значительно быстрее Microsoft, как в плане подходов к использованию инструментов тестирования, так и в плане развития самих инструментов тестирования.

Изоляция, в которой MS разрабатывала продукт и игнорирование практик TDD привели к тому что дефолтный интерфейс Visual Studio для запуска и просмотра результатов тестов очень неудобен.

Кроме того, есть серьезные проблемы со временем работы тестов:

Одна из главных причин медлительности MSTest — то, что для каждого запуска единичного теста, создаются копии ВСЕХ сборок в уникальной директории внутри папки "TestResults". Это может звучать не так страшно, но я заметил, что это замедляет выполнение тестов по крайней мере в 3-4 раза по сравнению с NUnit или TestDriven.NET (с MSTest). Я понимаю, что создание копий сборок каждого запуска позволяет накапливать историю о результатах тестирования для Team Foundation Server. Но, по крайней мере, эта фича должна быть опциональной. Крайне непрактично, что создается весь набор файлов для публикации в continuous integration сервере во время каждой сессии TDD (red-green-refactoring). Это полностью ломает ритм TDD.

Из статьи The fundamental problems and impracticality of using MSTest

MSTest жестко связан с Visual Studio, поэтому есть серьезные проблемы с интеграцией тестов в систему continuous integration, если на машине ci-сервера не установлена VS. Конечно, если вы используете Team Foundation Server, то проблем скорее всего не возникнет)

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

Microsoft’s own Patterns and Practices признает так же, что нет резона переходить с NUnit на MS Test.