VS Test step on TFS failing after all tests pass - unit-testing

I have a collection of MsTest and NUnit tests that are being run in TFS 2015 using the VS Test step. I'm using NUnit Test Adapter 3.4.1 to run the tests on the build agent.
At the end, even though the tests pass, Nunit seems to croak and the build step fails with these two errors.
2016-09-04T09:59:44.7209787Z ##[error]Error: Exception NUnit.Engine.NUnitEngineException, Exception thrown executing tests
2016-09-04T09:59:44.7209787Z ##[error]
2016-09-04T09:59:44.7209787Z ##[error]Error: Exception encountered unloading AppDomain
2016-09-04T09:59:44.7209787Z ##[error]
2016-09-04T09:59:44.7209787Z Information: NUnit Adapter 3.4.1.0: Test execution complete
2016-09-04T09:59:44.8615975Z Results File: C:\agent\_work2\1\TestResults\SRV-BLD1 2016-09-04 01_22_45.trx
2016-09-04T09:59:44.8615975Z Total tests: 139. Passed: 134. Failed: 0. Skipped: 5.
I've checked that there are indeed 139 tests in the suite, and 5 are set to ignore (2 are MSTest, and 3 are NUnit).
I'm not sure if there's a place to get more detailed explanation of the error. Searching this site and google seems to suggest that the NUnit.Engine.NUnitEngineException is linked to test discovery (here, and here for instance), but my tests are being discovered, so I'm not sure if this is related (Pretty new to NUnit, so not sure of a lot of things).
I also saw two links dealing with Adapter failures (here and here), but the errors don't quite match up, although maybe just because I don't have the same level of verbosity.
In TFS, the step doesn't have any configuration on it, just that it's enabled and the path to the DLLs.
Does anyone know what is causing the errors (which I'm assuming are causing the build to fail)? Alternatively, what should be the next steps in getting a more precise/verbose error stack to investigate the issue?
As a side note, I saw this SO answer, which states this:
MSTest.exe returned an exit code of 1 indicating that not all tests
passed.
I wasn't able to find any confirmation that VSTests fails when it encounters Skipped tests, but could this also be an issue?
Thank you for any help.
UPDATE
As suggested below, I tried running this from the IDE directly, and got this output (folders redacted)
------ Discover test started ------
NUnit Adapter 3.4.1.0: Test discovery starting
NUnit Adapter 3.4.1.0: Test discovery complete
========== Discover test finished: 139 found (0:00:00.8820879) ==========
------ Run test started ------
System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain. This can happen if the test(s) started a thread but did not stop it. Make sure that all the threads started by the test(s) are stopped before completion.
NUnit Adapter 3.4.1.0: Test execution started
Running all tests in C:\agent\_work2\1\s\codePorject\bin\Debug\codeProjectTests.dll
NUnit3TestExecutor converted 37 of 37 NUnit test cases
System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain. This can happen if the test(s) started a thread but did not stop it. Make sure that all the threads started by the test(s) are stopped before completion.
Exception NUnit.Engine.NUnitEngineException, Exception thrown executing tests
Exception encountered unloading AppDomain
NUnit Adapter 3.4.1.0: Test execution complete
========== Run test finished: 139 run (1:20:10.3290294) ==========
I've found a similar xUnit issue open, but it doesn't seem to have a solution.
This StackOverflow answer suggests to use a sleep timer, so I might try that.

In the end, it looks like some sort of a race condition between Firefox browser windows and nUnit. In my cleanup code, I'm killing firefox and iisexpress processes. Adding a sleep call has eliminated the issue:
public static void AssemblyCleanup()
{
foreach (var process in Process.GetProcessesByName("firefox")) process.Kill();
foreach (var process in Process.GetProcessesByName("iisexpress")) process.Kill();
System.Threading.Thread.Sleep(5000);
}

An NUnitEngineException is what it says: an exception that was discovered by the engine. It can be caused by many things and the message indicates the problem. In your case, the message says "Exception encountered unloading AppDomain" which means... well what it says.
The test adapter catches and handles the exception, producing the message you see. There is some indication that TFS also sees the exception and fails test run as a result. If you were to run this under the VS IDE, I think you would see the message from the adapter but the run would not fail. There is an NUnit3 Test Adapter issue about this, but it's not clear if the solution lies within the adapter or if it's a TFS problem.
If you do try this under the IDE I hope you will post the output window text from that run as well.

Related

How to find the test that caused a timeout

At least one of my tests hangs and causes the test run to abort eventually:
Aborting test run: test run timeout of 7200000 milliseconds exceeded.
Results File: D:\TF\2\s\TestResults\xxxxx.trx
Test Run Aborted.
Total tests: Unknown
Passed: 3261
Skipped: 1
Total time: 2,0003 Hours
##[warning]Vstest failed with error. Check logs for failures. There might be failed tests.
I'm using TFS 2018 and the Visual Studio Test task (2.3.28) to run unit tests built with Visual Studio 2019 16.4.5.
I started the test task with the additional parameters: /Blame -- RunConfiguration.TestSessionTimeout=7200000
A few days ago, the test suite ran successfully. It typically finishes within 10 minutes:
Results File: D:\TF\3\s\TestResults\xxxxxx.trx
Test Run Successful.
Total tests: 3336
Passed: 3335
Skipped: 1
Total time: 9.0574 Minutes
I examined the .trx file and found the test that was skipped.
But there was no hint about the tests that were skipped due to the abortion and what test caused the time out.
How do I find the problematic test?
Edit:
When examining the .trx file, display the Start Time column and sort it descending. The tests that most recently started may indicate which DLL may be the culprit. Alas, that doesn't provide a definite answer which test(s) were running when the timeout occurred.
If you mean you want information like the screenshot below, you need to use Visual Studio 2019 to do the tests.
The definition looks like below:

Which unit test is currently running?

This question is related to the problem where my unit test procedure is crashing but I don't know on which unit test.
I realise this question is a duplicate of How can I find out which test method in a batch of test methods fails to run? but I need to try anyway:
I'm running some unit tests (about 118 of them), but one of them seems to make the Visual Studio unit test environment crash. This is what I see in the "output" window's "Tests" tab:
[5/02/2018 11:13:18 Informational] ------ Run test started ------
[5/02/2018 11:13:38 Error] The active Test Run was aborted because the execution process exited unexpectedly. The test execution process crashed while running the tests. To investigate further, open file:///C:/Users/DominiqueDS/AppData/Local/CrashDumps/vstest.executionengine.x86.exe.19136.dmp file in Visual Studio and choose "Debug in mixed mode".
[5/02/2018 11:13:38 Informational] ========== Run test finished: 65 run (0:00:19,6926824) ==========
The reason that I have that dump file is thanks to my Windows configuration which automatically creates such dumpfiles in case of a crashing application. (The procedure for this configuration is found under this URL)
Examining the dump file gives me more information on the test, which is failing: I have a hunch where I can find it, and in another thread, I find a function, calling a method which seems to contain the name of the unit test I'm running.
Although I know which test is failing, it's based on hunches and on dumpfiles I should even not generate, so I'm looking for another solution:
In the function TEST_METHOD in the file "c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Auxiliary\VS\UnitTest\include\CppUnitTest.h", I've tried to add the following lines:
cout << "Test : ";\
cout << methodName;\
cout << "\n";\
I was hoping that this would show every test I wanted to run, but instead I get the error message that this is wrong (also using std::cout and OutputDebugString() function seems not to be allowed).
Hence my question: does anybody know a way to find out, in case one of my unit tests makes my test environment crash, how can I find out which test this is, without needing to generate and debug the Visual Studio dumpfile?
For your information: looking in the "Test Explorer" is not helping: I have a list of disabled tests, a list of successful ones, and a list of some which are not finished, and my failing test is not the first of the "not finished" ones.
Found it: I've added the following line in the definition of TEST_METHOD():
Microsoft::VisualStudio::CppUnitTestFramework::Logger::WriteMessage(L#methodName);\

Not getting any test results with xunitmultiprocess

I am running tests through Jenkins on a windows box. In my "Execute Windows Batch command" portion of the project configuration I have the following command:
nosetests --nocapture --with-xunitmp --eval-attr "%APPLICATION% and priority<=%PRIORITY% and smoketest and not dev" --processes=4 --process-timeout=2000
The post build actions have "Publish JUnit test result report" with the Test report XMLs path being:
trunk\automation\selenium\src\nosetests.xml
When I do a test run, the nosetests.xml file is created, however it is empty, and I am not getting any Test Results for the build.
I am not really sure what is wrong here.
EDIT 1
I ran the tests with just --with-xunit and REM'd out the --processes and got test results. Does anyone of problems with xunitmp not working with a Windows environment?
EDIT 2
I unstalled an reinstalled nose and nose_xunitmp to no avail.
The nosetest plugin for parallelizing tests and plugin for producing xml output are incompatible. Enabling them at the same time will produce the exact result you got.
If you want to keep using nosetest, you need to execute tests sequentially or find other means of parallelizing them (e.g. by executing multiple parallel nosetest commands (which is what I do at work.))
Alternatively you can use another test runner like nose2 or py.test which do not have this limitation.
Apparently the problem is indeed Windows and how it handles threads. We attempted several tests outside of our Windows Jenkins server and they do not work either. Stupid Windows.

vstest.executionengine.x86.exe not closing

I've encountered an error when running unit tests. If I Debug the unit tests vstest.executionengine.x86.exe runs, then closes when the tests pass.
If I just run the tests (Even if the test is as simple as just creating a new list, with no asserts) vstest.executionengine.x86.exe doesn't close and stays running in task manager.
This is causing an issue for me when it comes to writing more complicated tests that include removing files / cleaning up sqllite databases.
Any help would be appreciated.
EDIT :
Steps to reproduce :
Create New Unit Test Project
Debug Unit Tests - vstest.executionengine.x86 opens and closes, test passes.
Run Unit Tests - vstest.executionengine.x86 opens and stays open
This is by design.
The vstest.executionengine.exe is restarted only when we detect a change in the configuration between two consecutive test runs. This helps ensure we aren't taking a perf hit on process restarts unnecessarily.
Product Update
With VS2013 we have a new menu item under Test -> Test Settings called "Keep Test Execution Engine Running". You can uncheck this to opt out of the default behavior.
I worked around this by using the following as a pre-build event on the affected test projects:
for 64-bit:
taskkill /F /IM vstest.executionengine.exe /FI "MEMUSAGE gt 1"
or for 32-bit:
taskkill /F /IM vstest.executionengine.x86.exe /FI "MEMUSAGE gt 1"
This silently kills the execution engine before building the test project. The /FI "MEMUSAGE gt 1" stops the command (and therefore the build) from failing if the execution engine isn't running.
For what its worth, I ran into this same situation and it turned out that I had a test that did not properly clean up all of its resources. In my specific case there was a background thread with a network connection open that did not get closed before the test exited. Not sure why exiting the test did not close this for me, but when i fixed my code to properly dispose of all the resources I opened, everything worked as expected. I did not have to add any hacks to kill the vstest.executionengine.exe, nor did I have to opt out of Test -> Test Settings -> Keep Test Execution Engine Running
I had this issue when running test using Resharper's test runner which doesn't seem to respect the Test-->Test Settings-->Keep Test Execution Engine Running setting. In my case it was causing the build to fail with the following error:
warning MSB3026: Could not copy "...\SQLite.Interop.dll" to "bin\Debug\x86\SQLite.Interop.dll". Beginning retry 10 in 1000ms. The process cannot access the file 'bin\Debug\x86\SQLite.Interop.dll' because it is being used by another process.
Adding a pre-build event to the test project as #HappyCat suggested worked for me. I also needed to wrap it in an if statement to prevent it from running on the build server and interfering with other jobs.
if $(ConfigurationName) == Debug (
echo "attempting to kill vstest to prevent access denied on sqlite.interop.dll"
taskkill /F /IM vstest.executionengine.x86.exe /FI "MEMUSAGE gt 1"
)
I know this is old but I thought I'd throw in something I just discovered.
A test I was running had some objects in it that implemented IDisposable, so the code analysis told me so should my test class. It took a while to realize it, but when this.Dispose(); was getting called on the implementation of that interface when I put it on my test class, it was actually throwing a StackOverflow exception. So I just yanked the interface and let CA continue to whine.
I did not need to toggle 'Keep Test Execution Engine Running'.
The easiest approach is to go to windows task manager. Look out for vstest.executionengine.exe process running in the background. Kill that process and it should work fine now.

MSBuild: build results shows 'no code coverage' while importing test-result does

I have a strange problem,
my MSBuild runs tests, code-coverage and publishing fine (part of the build.txt shown):
Results Top Level Tests
------- ---------------
Passed BuildTestProject.UnitTest1.TestMethod1
Passed BuildTestProject.UnitTest1.TestMethod2
2/2 test(s) Passed
...
Results file: W:\BuildWorkspace\XXX\Test Release\TestResults\XXX_XXX 2009-08-20 11_47_09_Any CPU_Release.trx
Run Configuration: Local Test Run
Waiting to publish...
Publishing results of test run XXX#XXX 2009-08-20 11:47:09_Any CPU_Release to http://XXX:8080/Build/v1.0/PublishTestResultsBuildService2.asmx...
....Publish completed successfully.
When I import these testresults on my local machine i get to see the code coverage-data as expected. But the code-coverage details are not shown in the details of the build that Visual Studio shows when you expand the 'results details'.
Any tips?
Finally found the solution today, found out that my TeamFoundationServer itself had problems with publishing the results to my buildAgent. I read somewhere (after searching for CoverAn.exe) that it is installed as a service, then i checked the credentials for the service 'Code Coverage Analysis Service'.
These were running under TFSMachine\NETWORK instead of our service-account for the TeamFoundationServer. Changed this, reran a build with tests in it and it now publishes the results.
W00t!
Check that the .testrunconfig used by the server has coverage enabled. It may be different than your local .testrunconfig.