Почему Run All вызывает сбои в тестировании модуля VS2012, но работает один за другим?

Мы просто "обновились" от Visual Studio 2008 до Visual Studio 2012. Мы обновили наши модульные тесты, и теперь они передаются при их запуске по отдельности, но когда я пытаюсь запустить все, я получил следующую ошибку:

The active Test Run was aborted because the execution process exited unexpectedly. To investigate further, enable local crash dumps either 
at the machine level or for process vstest.executionengine.appcontainer.x86.exe. Go to more details: [http://go.microsoft.com/fwlink/?linkid=232477][1]

Итак, я пошел в link и последовал инструкциям, чтобы добавить раздел реестра для включения локальных аварийных дампов. Затем сообщение об ошибке изменилось на:

The active Test Run was aborted because the execution process exited unexpectedly. Check the execution process logs for more information. 
If the logs are not enabled, then enable the logs and try again.

Видимо, он заметил изменения, которые я внес в реестр, чтобы включить сбой. Однако, когда я смотрел в% LOCALAPPDATA%\CrashDumps, файлы не создавались.

Если я запускаю один тест за раз (или даже несколько тестов за раз), я могу заставить их всех пройти. Проблема заключается только в Run All.

Кто-нибудь еще сталкивался с подобными проблемами? Если да, то как вы их решили?

По сути, тот же вопрос задавался MSDN, но ответ был чем-то вроде "нажмите ссылку на свалку сбоя". Этот ответ не помогает мне, потому что я не вижу никакой ссылки на дамп аварийной ситуации, и я не могу получить сбой аварийной ситуации.

Этот вопрос в StackOverflow также схож, и в итоге получилась ошибка регистрируемая на Microsoft Connect (который по некоторым причинам откладывается), но моя проблема может быть иной, потому что мой код не имеет ничего общего с "асинхронными задачами" (я не думаю).

EDIT: проблема исчезла, по-видимому, сама по себе, но проблема, вероятно, была исключением, которое не попало в код unit test, как предлагают некоторые из приведенных ниже ответов. Тем не менее, я все еще смущен, почему проблема возникла только при запуске All, а не при запуске небольших групп тестов или Debug All.

Ответ 1

У меня была та же проблема, тесты не прошли, по всей видимости, без причины. Позже я обнаружил, что багги-метод вызывает StackOverflowException. Когда я исправил свою ошибку, ошибка VS исчезла.

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

Ответ 2

Лучшим обходным решением, которое я до сих пор, является отладка всех. Это делается через TEST → Debug → All Tests. Он явно медленнее, но он не падает.

Ответ 3

Для всех, кому это может понадобиться в будущем: мой тестовый бегун сработал, когда с помощью unit test была выполнена консольная команда (Environment.Exit(-1);). Даже работа в режиме отладки просто сбой - я не мог получить полезное сообщение об ошибке.

Итак, мой сценарий отличается от основного сценария вопроса тем, что: а) отладка вообще не работала; б) запускать все vs запуска индивидуально не делало разницы. Это связано с тем, что мой сценарий ошибок всегда возникал, но переполнение стека исходного вопроса не выполнялось.

В нижней строке: тестовый бегун плох и сработает, если он найдет что-то, что ему не нравится. Вам нужно вручную изолировать и определить, что такое Bad Thing ™.

Ответ 4

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

Таким образом, решение должно запускать все тесты в отладке (из меню Test → Debug), а Visual Studio будет показывать такие ошибки.

Ответ 5

Для кого-то другого, ищущего это: у меня был код, который вызывал System.Environment.Exit(123), и я не знал об этом. Поэтому проверьте наличие любого кода, который завершает процесс.

Ответ 6

У меня была такая же проблема. Оказалось, что это был мой код - был бесконечный цикл вызовов службы WCF. В вашем случае это может быть что-то другое. Итак, мое предложение состоит в том, чтобы либо помнить (регистрируется в системе контроля версий?), Либо вычислять (исключая различные тесты из цикла, например, с помощью метода деления пополам), которые помещаются в код, приводят к такому поведению. И wuala! Это вызывает проблему и в то же время ошибка в коде.

UPDATE Что касается вопросов в вашем EDIT. Может случиться так, что работа с небольшими группами тестов не воспроизвела проблему. В этом случае, учитывая, что эти группы включали все тесты, можно предположить, что некоторые тесты мешают. Может быть, некоторые статические данные или поля в тестовом классе? Что касается запуска тестов в режиме отладки - я не удивлен. Тестер Visual Studio ведет себя по-разному в режиме "Выполнить" и "Отладка".

Ответ 7

У меня была аналогичная проблема, за исключением того, что это не исключение stackoverflow. Это было вызвано тестированием моего проекта с использованием Entity Framework и проекта Nunit без ссылок, включенных в модули EntityFramework и EntityFramework.SqlServer. Добавление ссылок на модули Entity Framework исправило его.

Ответ 8

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