Без сомнения утечки памяти. Особенно, когда Вы делаете вещам нравится, динамично создают средства управления и добавляют обработчики в ASP.NET. На Загрузке Страницы.
Я могу указать вам на пару блогов о недовольстве MSTest:
Честно говоря, эти люди пытаются установить MSTest на серверах сборки, отличных от TFS. Некоторые из их проблем не применимы к вашей ситуации.
Мы, в первую очередь, магазин Microsoft и используем TFS для контроля версий. Однако мы используем TeamCity для непрерывной интеграции; нам это нравится, и он достаточно хорошо интегрируется с TFS. Я никогда не использовал MSTest; мы использовали NUnit в течение многих лет и не видели причин для изменений.
MSTest должен иметь тесную интеграцию с Team Suite, что (поскольку ваша компания уже заплатила за это огромную плату) является важным моментом в ее
NUnit поставляется с меньшей привязкой к поставщику и имеет богатый API. Как отметил serg10, синтаксис Assert.That особенно мощный и элегантный.
В конце концов, вы можете писать хорошие модульные тесты без всех причудливых функций. Некоторые из них могут даже мешать (это теория, лежащая в основе xUnit.net ). Я бы порекомендовал вашей команде стандартизировать одну платформу тестирования; избегайте наличия некоторого кода в MSTest и другого кода в NUnit.
Я думаю, что написание хороших тестов важнее, чем выбор фреймворков. Прочтите Искусство модульного тестирования: с примерами в .NET , напишите несколько тестов, а затем посмотрите, подходит ли MSTest для нужд вашей команды.
РЕДАКТИРОВАТЬ: В приложении B «Искусство модульного тестирования» есть некоторые хорошие комментарии к Microsoft Unit Testing Framework. В нем упоминается YUnit как пример того, насколько громоздко расширять MSTest. Однако,
NUnit has a richer assert API. The api is particularly elegant (fluent, even), for example
Assert.That(Is.Unique, myResults); // assert: myResults is a collection of unique items
If you've seen the Hamcrest extensions to JUnit you'll recognise this style.
It also has a growing set of extensions, such as performance testing and an excellent VS plugin.
Я работал над первоклассной поддержкой MSTest в TestDriven.Net 3.0. В предыдущих версиях поддержка MSTest была очень простой (похоже, мало кто использовал MSTest).
Начиная с TestDriven.Net 3.0 Beta 2, имеется довольно полная поддержка всех атрибутов MSTest, связанных с модульным тестированием. Существует даже поддержка тестов на основе данных с использованием атрибута DataSource. Ваши тесты также будут выполняться на скоростях, близких к NUnit!
Если вы используете MSTest, мне было бы интересно узнать, не сработает ли какой-либо из ваших модульных тестов при выполнении с использованием TestDriven.Net 3.0 Beta 2 (или более поздней версии).
Пожалуйста, попробуйте его в своих проектах MSTest и дайте мне знать, как у вас дела: http://www.testdriven.net/download.aspx
ПРИМЕЧАНИЕ, он не поддерживает атрибуты DeploymentItem или HostType. Вы можете использовать настройку элемента проекта «Копировать в выходной каталог» вместо DeploymentItem.
Вы можете изменить код в NUnit, потому что это открытый исходный код. Вы не можете этого сделать с MSTest.
Рой, часть вашей информации устарела, особенно в отношении 2010 года;
Nunit содержит атрибут [TestCase], который позволяет реализовать параметризованные тесты. В MSTest этого нет
Это может быть реализовано с помощью расширяемости юнит-тестов в 2010 году.
Атрибут ExpectedException в MSTest имеет ошибку, когда ожидаемое сообщение никогда не утверждается, даже если оно неверно - тест пройдет.
Правильно, это все еще там
NUnit имеет API Assert.Throws, позволяющий тестировать исключение на конкретной строке кода вместо всего метода (вы можете легко реализовать это самостоятельно)
Джим внедрил версию Assert.Throws для MSTest в то же время, когда он сделал оригинальную реализацию для NUnit, NUnit включил в последующие выпуски, MSTest - нет, но ее все еще можно использовать.
NUnit содержит беглую версию Assert API (как уже упоминалось - Assert.That...)
Для MSTest есть несколько таких реализаций от сторонних разработчиков
NUnit намного быстрее
См. комментарий Джейми, ему удалось заставить MSTest работать быстрее :-)
NUnit может запускать тесты в 32 и 64 бит (MSTest запускает их только в 32 бит IIRC)
Не в 2010, поддержка 64 бит встроена.
NUnit позволяет абстрактным классам быть тестовыми приспособлениями (так что вы можете наследовать тестовые приспособления). MsTest этого не делает.
Это работает, но не для всех сборок, что ограничивает его полезность.
NUnit позволяет непубличным классам быть тестовыми приспособлениями (начиная с последней версии)
Все еще там
NUnit был создан ТОЛЬКО для идеи модульного тестирования. MSTest был создан для тестирования - и также немного юнит-тестирования.
Правильно, существует много заблуждений, что MSTest - это то же самое, что и Nunit, но MSTest - это обобщенный фреймворк.
NUnit содержит PNunit (выполнение параллельных тестов с NUnit). В MSTest эта возможность появилась только в vs 2010
Правильно, есть настройка конфигурации XML, которая позволяет контролировать степень параллелизма.
У меня есть хороший способ между MsTest и NUnit. Вы можете использовать платформу MSTest для запуска вашего теста (атрибут TestClass и TestMethod для каждого теста), но используйте NUnit Assert API.
просто сделайте следующее:
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Assert = NUnit.Framework.Assert;
теперь вы можете использовать Assert.That (..) и по-прежнему иметь автоматическую сборку TFS и отчет о тестировании. ваш тест можно запустить в VS, TestDriven.net или Resharper, не имеет значения, тест завершится неудачно или пройдет правильно, и результат ошибки будет соответствовать структуре NUnit.
см. Здесь: http://alsagile.com/archive/2010/03/09/stop-the-war-between-nunit-and-mstest-make-them.aspx
См. http://fluentassertions.codeplex.com . Вы можете делать такие вещи, как
"ABCDEFGHI".Should().StartWith("AB").And.EndWith("HI").And.Contain("EF").And.HaveLength(9);
new[] { 1, 2, 3 }.Should().HaveCount(4, "because we thought we put three items in the
collection"))
dtoCollection.Should().Contain(dto => dto.Id != null);
collection.Should().HaveCount(c => c >= 3);
dto.ShouldHave().AllPropertiesBut(d => d.Id).EqualTo(customer);
dt1.Should().BeWithin(TimeSpan.FromHours(50)).Before(dt2);
Action action = () => recipe.AddIngredient("Milk", 100, Unit.Spoon);
action
.ShouldThrow<RuleViolationException>()
.WithMessage("Cannot change the unit of an existing ingredient")
.And.Violations.Should().Contain(BusinessRule.CannotChangeIngredientQuanity