Я помогаю команде, чьи сборки начали сбой из-за сбоев теста.
Ошибки вызваны отсутствием конфигурации строки подключения. Я проверил обычные проблемы в отношении файла конфигурации, чтобы убедиться, что строка соединения была указана именно с правильным именем.
В итоге я получил полный путь к файлу конфигурации, чтобы проверить, что тот, что на сервере сборки, содержит точную конфигурацию, которая ожидалась.
AppDomain.CurrentDomain.SetupInformation.ConfigurationFile
Путь не указывал на файл TestProject.exe.config
, а вместо этого указывал на vstest.executionengine.x86.exe.Config
в следующем месте:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.executionengine.x86.exe.Config
Этот файл не содержит никаких строк соединения.
Когда я выписываю все доступные строки подключения из конфигурации, я получаю строку подключения по умолчанию:
Имя: LocalSqlServer Connection: источник данных =.\SQLEXPRESS; Integrated Security = SSPI; AttachDBFilename = | DataDirectory | aspnetdb.mdf; User Instance = true. Прекращение выполнения теста.
Это происходит из файла machine.config
(kudos petelids).
Поэтому большой вопрос:
Почему используется vstest.executionengine.x86.exe.Config
, а не app.config
(во время выполнения TestProject.exe.config
)? (Я могу догадаться, что это связано с тем, что запущен процесс - это тестовый бегун, но я считаю справедливым сказать, что вы ожидаете, что тестирующее средство предложит тестовому проекту использовать собственный конфигурационный файл, что обычно происходит).
По умолчанию MSTest запускает тесты в изолированном режиме.
Решение этой проблемы состояло в том, чтобы добавить новый тестовый проект и перенести тесты на него.
Новый проект вел себя как и все другие проекты, запуская тесты в изолированном процессе и используя файл app.config из тестового проекта.
Я делаю это причудой.
Я думаю, справедливо сказать, что вы ожидаете, что тестирующее средство предложит тестовому проекту использовать собственный файл конфигурации, что обычно происходит
Это совершенно истинное предположение при работе с NUnit, xUnit и т.д., Но не с Microsoft Test Runners (MSTest и VSTest). Они просто игнорируют конфигурационный файл целевой сборки и используют собственную конфигурацию.
Существует два решения этой проблемы:
/noisolation: Run tests within the MSTest.exe process. This choice improves test run speed but increases risk to the MSTest.exe process.
msdn.microsoft.com/en-us/library/ms182489.aspx
%windir%\Microsoft.NET\Framework\[version]\config\machine.config
или%windir%\Microsoft.NET\Framework64\[version]\config\machine.config
для 64-разрядных