Тестирование в Visual Studio преуспевает индивидуально, сбой в наборе

Когда я запускаю свои тесты в Visual Studio индивидуально, все они проходят без проблем. Однако, когда я запускаю всех из них сразу, некоторые проходят, а некоторые терпят неудачу. Я попытался сделать паузу в 1 секунду между каждым методом тестирования без успеха.

Любые идеи? Заранее благодарим за помощь...

Ответы

Ответ 1

Возможно, у вас есть общие данные. Проверьте наличие статических переменных-членов в используемых классах, что означает, что один тест устанавливает значение, которое приводит к сбою последующего теста.

Вы также можете отлаживать модульные тесты. В зависимости от используемой структуры вы должны будете запустить средство framework в качестве приложения запуска отладки, передающего путь к скомпилированной сборке в качестве параметра.

Ответ 2

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

Ответ 3

Все, вероятно, правы, какая-то общая дата изменяется между тестами. Но обратите внимание на порядок выполнения MS Test. Просто пауза между тестами не является решением. Каждый тест выполняется в его собственном экземпляре тестового класса в отдельном потоке.

Ответ 4

в соответствии с другими ответами. Похоже, что у вас есть синглтон или глобальная переменная, вызывающая взаимодействие.

Ответ 5

Другие unit test фреймворки, которые я использовал, усердно работают, чтобы гарантировать, что тест дает идентичные результаты независимо от того, выполняется ли тест отдельно или выполняется как часть альтернативы "запустить все". Цель состоит в том, чтобы предотвратить один эффект от воздействия на другой из-за побочных эффектов, таких как (например), имеющих один тест, оставить статическое состояние класса в конфигурации, которую другой тест не ожидает. Структура VS unit test, похоже, не обеспечивает эту изоляцию. У меня есть 2 предложения по минимизации тех проблем, которые задает этот вопрос. Во-первых, используйте нестатический класс, предпочитающий статический класс, если класс имеет состояние (имеет что-то иное, чем статические методы). Создайте один экземпляр этого класса и сохраните информацию о состоянии, которая хранится в статическом классе. Во-вторых, если вы предпочитаете статический класс со статическим состоянием, у вас есть статический метод, который устанавливает статическое состояние обратно в "пустое" (например, метод, который устанавливает все статические свойства в null/zero/etc.). Вызовите это в конце каждого unit test, чтобы отменить любые эффекты, которые тест наложил на статическое состояние. (Это, по общему признанию, менее элегантное, но может быть работоспособным, если сделано в умеренных количествах). Или сделайте то, что я планирую сделать, - найдите структуру unit test, которая обеспечивает изоляцию между тестами.

Ответ 6

Я также столкнулся с этой проблемой, хотя моя проблема оказалась проблемой с потоками. В моем случае я подделывал объект HttpContext, поскольку тесты основывались на его существовании. Тем не менее, я устанавливал это в методе ClassInitialize, думая, что это будет использоваться для каждого метода, как показано ниже:

[ClassInitialize]
public static void ClassInit(TestContext testContext)
{
    HttpContext.Current = new HttpContext(new HttpRequest(null, "http://tempuri.org", null), new HttpResponse(null));
}

Однако оказывается, что каждый тестовый метод в классе работает в отдельном потоке. Поэтому мне пришлось добавить этот код к каждому методу тестирования, который полагался на него, чтобы исправить эту проблему.

[TestMethod]
public void TestMethod1()
{
    HttpContext.Current = new HttpContext(new HttpRequest(null, "http://tempuri.org", null), new HttpResponse(null));
    ...
}

[TestMethod]
public void TestMethod2()
{
    HttpContext.Current = new HttpContext(new HttpRequest(null, "http://tempuri.org", null), new HttpResponse(null));
    ...
}

См. ссылку для получения дополнительной информации об этом. http://blogs.msdn.com/b/nnaderi/archive/2007/02/17/explaining-execution-order.aspx