Is there a way to hide or fix this nunit warning (I have the latest one: 3.17)? or why is this triggered at the end of the running tests?
[06.10.2020 PM 06:20:33 Warning] Exception NUnit.Engine.NUnitEngineUnloadException, Exception thrown unloading tests from D:\Git\Tests\Test\bin\x86\Debug\Test.dll
[06.10.2020 PM 06:20:33 Warning] Unable to unload application domain: unload thread timed out after 30 seconds.
Application domain was unloaded before all details could be read.
[06.10.2020 PM 06:20:33 Warning] at NUnit.Engine.Services.DomainManager.DomainUnloader.Unload()
at NUnit.Engine.Runners.TestDomainRunner.UnloadPackage()
at NUnit.Engine.Runners.AbstractTestRunner.Unload()
at NUnit.Engine.Runners.MasterTestRunner.UnloadPackage()
at NUnit.Engine.Runners.MasterTestRunner.Unload()
at NUnit.VisualStudio.TestAdapter.NUnitEngine.NUnitEngineAdapter.CloseRunner()
at NUnit.VisualStudio.TestAdapter.NUnit3TestExecutor.RunAssembly(String assemblyPath, IGrouping`2 testCases, TestFilter filter)
[06.10.2020 PM 06:20:33 Informational] NUnit Adapter 3.17.0.0: Test execution complete
[06.10.2020 PM 06:20:33 Error] An exception occurred while invoking executor 'executor://nunit3testexecutor/': Exception encountered unloading application domain
Exception encountered unloading application domain: Attempted to access an unloaded appdomain. (Exception from HRESULT: 0x80131014)
Application domain was unloaded before all details could be read.
[06.10.2020 PM 06:20:33 Informational] ========== Run test finished: 1 run (0:03:11.1407897) ==========
@marius02 If you create a small repro and raise an issue at the NUnit3TestAdapter repo https://github.com/nunit/nunit3-vs-adapter it might be possible to fix. Hiding it, you can't. It is an exception, and we can't hide them . I see the exception starts down in the engine, so it can be an NUnit engine issue too, but if we start from the adapter we can take it from there. But, we do need a repro :-)
I was wondering if I could get a summary of the v4 nunit adapter and why the major version change?
Wasn't quite sure what benefits/differences it would bring over the v3 adapter
I typically try to keep my projects on the latest of each, but couldn't find much outside https://docs.nunit.org/articles/vs-test-adapter/Adapter-Release-Notes.html on the new preview adapter
Wasn't quite sure what benefits/differences it would bring over the v3 adapter
I typically try to keep my projects on the latest of each, but couldn't find much outside https://docs.nunit.org/articles/vs-test-adapter/Adapter-Release-Notes.html on the new preview adapter
@tannergooding The reason for the major version change is that the way v4 interacts with the nunit.engine has been completely rewritten. The v3 version is heavily dependent on using XML internally all over the adapter code.
In v4 this has changed to transforming the xml to an object model at the time it is loaded from the engine, and then working on the object model instead. This brings back the Explicit feature, and the intention is to pave the way for other changes we can do. Further, under discussion is a possible drop of supporting the vsix variant, and also set the minum supported framework version to 4.5. Due to the internal rewrite there might be a intermittent loss of some features, we got one in the alpha.1 version, which is fixed now for the beta, but there might me more. However, there are around 20000 downloads now, with very few issues reported, so it might be better then feared. The changes will also pave the way for a possible better handling of the FQN issues we have - which are very annoying, and which are near impossible to handle in v3. We still need some more from MS in order to do this, but v4 should then be able to handle it. When the adapter was first written back in 2011/2012 it was a much simpler "thing" than it has become over the years. At that time the XML approach was ok, but now, the code is simply too cluttered to continue.
In v4 this has changed to transforming the xml to an object model at the time it is loaded from the engine, and then working on the object model instead. This brings back the Explicit feature, and the intention is to pave the way for other changes we can do. Further, under discussion is a possible drop of supporting the vsix variant, and also set the minum supported framework version to 4.5. Due to the internal rewrite there might be a intermittent loss of some features, we got one in the alpha.1 version, which is fixed now for the beta, but there might me more. However, there are around 20000 downloads now, with very few issues reported, so it might be better then feared. The changes will also pave the way for a possible better handling of the FQN issues we have - which are very annoying, and which are near impossible to handle in v3. We still need some more from MS in order to do this, but v4 should then be able to handle it. When the adapter was first written back in 2011/2012 it was a much simpler "thing" than it has become over the years. At that time the XML approach was ok, but now, the code is simply too cluttered to continue.
@tannergooding About the benefits in v4, in addition to bringing back the Explicit feature (and better than it was before), v4 is generally faster, and will handle large amount of tests much better. Further, with an upcoming fix in NUnit itself we can skip the pre-execution discovery phase completely, thus making the adapter even faster. This will not be possible to do with the v3 code base.
@mikkelbu Wow, I missed this:
do you know if it will be a problem that our pdb files mentions unknown files (or more precisely temp-files)?
I don't know of any downside to this. It's been the norm for pdb files to not be found.
I like to use <EmbedAllSources>true</EmbedAllSources> in my Directory.Build.props though.
2 replies
---------- Starting test discovery ----------
NUnit Adapter 3.17.0.0: Test discovery starting
NUnit Adapter 3.17.0.0: Test discovery complete
NUnit Adapter 3.17.0.0: Test discovery starting
NUnit Adapter 3.17.0.0: Test discovery complete
NUnit Adapter 3.17.0.0: Test discovery starting
NUnit Adapter 3.17.0.0: Test discovery complete
No test is available in C:\Git\_GuOrg\Gu.Reactive\Gu.Wpf.Reactive\bin\Debug\net46\Gu.Wpf.Reactive.dll C:\Git\_GuOrg\Gu.Reactive\Gu.Reactive\bin\Debug\net46\Gu.Reactive.dll. Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.
========== Test discovery finished: 1279 Tests found in 7,9 sec ==========
^ is confusing, it both says tests were found and not
No tests run by visual studio runner, resharper runner runs the tests like always
You cannot do it directly, but one possibility is something like
[Test]
public void Test()
{
var data = 14;
var assertions = new List<Action>
{
() => Assert.That(data, Is.EqualTo(4)),
() => Assert.That(data, Is.EqualTo(6)),
() => Assert.That(data, Is.EqualTo(8))
};
Assert.Multiple(() =>
{
foreach (var assertion in assertions)
{
assertion.Invoke();
}
});
}
@JohanLarsson The No test found refers to that specific dll. The other discoveries seems to have found 3 more dlls. I agree it could also display the name of those. It is more concerning that REsharper runs the tests and VS doesn't. IS there anything in the Output Test window ?
Maybe that explains it, chances are r# handles it differently
What is fqn?
If you see the issues list on github, you can filter on FQN.....
I've been using the r# runner pretty much exclusively for many years, try the ms runner every now and then and it has improved the last year
yes, it has improved, true.... just wish they had got the FQN thingy better sorted. We're kind of helpless since this happens in the interaction with them. We do have some runsettinsg that can help it, but they have other sideeffects. So, we just have to wait there. The error you get above is coming from the embedded vstest, and not from the adapter. You can turn on the Dump discovery feature and see if that displays anything, but it might crash before that too. Also, if you have the REal Time Discovery on, turning that off could possible show something.
It would be interesting to see the signature of the test that causes the exception though
I am using NUnit with VS 2019 and writing unit tests. When using parameterized tests, the tests are showing up in Test Explorer with namespace.class.method. I have literally tried for hours to change this. I found a couple sites online how to change that but I just can't get it to change. http://hermit.no/how-to-change-visual-studio-test-explorer-testnaming-using-nunit/ and NUnit docs: https://docs.nunit.org/articles/nunit/running-tests/Template-Based-Test-Naming.html#modifying-the-name-format I created a .runsettings file with <NUnit> that has "<DefaultTestNamePattern>{m}</DefaultTestNamePattern>" in it. No luck. Currently I have "MyNamespace.MyClass.DGTest(3)" showing in Test Explorer. I would prefer to just have DGTest(3) where it expands to show the three specific test cases below. Is it still a valid feature? Am I doing the right thing to change the test name format?
Hi @darrenge I don't know of a way to view just the method/display name in test explorer.
You can use the group by functionality of test explorer to group tests by class name and thus remove the namespace from the view.
In my understanding changing the DefaultTestNamePattern is changing how the NUnit test adapter reports test names to the vstest platform (and therefore will change how they are shown in the test explorer window) but the default test name pattern is just for changing the 'method/display name' part of the name (which probably explains why you're not getting the outcome you desire).
You can use the group by functionality of test explorer to group tests by class name and thus remove the namespace from the view.
In my understanding changing the DefaultTestNamePattern is changing how the NUnit test adapter reports test names to the vstest platform (and therefore will change how they are shown in the test explorer window) but the default test name pattern is just for changing the 'method/display name' part of the name (which probably explains why you're not getting the outcome you desire).
You can also try grouping just by 'traits' which will group by NUnit test categories. If you aren't using test categories it may give you the outcome you want but I'm not sure because i use categories
Thanks for getting back to me. Shoot. We use the Group By with test categories but this is all part of the actual name and not the groupings. One of the response that confused me "the DefaultTestNamePattern is changing how the NUnit test adapter reports test names to the vstest platform (and therefore will change how they are shown in the test explorer window)". From the sounds of that statement, I should be able to change the DeafultTestNamePattern and just show the method name and not the fully qualified name. If you are curious on the code, it is all in Github at https://github.com/microsoft/FASTER/tree/master/cs/test
@darrenge The TestExplorer is responsible for the groupings marked in yellow above. The adapter/framework is responsible for the names in the red blocks above. The adapter can not change the way teh testexplorer handles its groups, since that is based on the FQN. What is coming in the red boxes however we can, and that is controlled by two properties in the runsettings. The one you refer to, which is sent down to the framework, and controls how the display name is reported. The term "display name" is a bit misleading, since it is really the Test Name that is changed, or even more precise, the Name of the Test. If we look at the output from the framework it comes in two steps, the discovery gives us the full information, which for a parametrized test looks like: ````<test-case id='0-1004' name='ThatMethodsAlsoWorks(42,True)' fullname='WrapThat.Tests.Answers.ThatMethodsAlsoWorks(42,True)' methodname='ThatMethodsAlsoWorks' classname='WrapThat.Tests.Answers' runstate='Runnable' seed='1730380949' />
where you see the name property and the fullname property, the latter being the same as the FQN in the Test Explorer. The last adapter property is the DisplayName setting, which can be either Name or FullName, and if you try to switch this to FullName you will see it affects ONLY the names used in the red boxes above. Changing the DefaultTestNamePattern as you did, will only change the displayname to contain the method and not the parameters, so it will look like the screenshot aboce, with multiple results shown for the parametrized test:
where you see the name property and the fullname property, the latter being the same as the FQN in the Test Explorer. The last adapter property is the DisplayName setting, which can be either Name or FullName, and if you try to switch this to FullName you will see it affects ONLY the names used in the red boxes above. Changing the DefaultTestNamePattern as you did, will only change the displayname to contain the method and not the parameters, so it will look like the screenshot aboce, with multiple results shown for the parametrized test:
Does anyone know a way to see which category the currently running TestFixture has?
@johan-eriksson Currently, that is not possible from within the test. However, you can access this from
OneTimeSetUp or OneTimeTearDown, see e.g. nunit/docs#286 or nunit/nunit#2674