Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 18 22:45
    KalleOlaviNiemitalo commented #3724
  • Jan 18 22:15
    Build #6990 passed
  • Jan 18 22:10

    rprouse on master

    Don't install .NET Core 5.x SDK… Merge pull request #3734 from n… (compare)

  • Jan 18 22:10

    rprouse on 3724b

    (compare)

  • Jan 18 22:10
    rprouse closed #3734
  • Jan 18 22:10
    rprouse closed #3724
  • Jan 18 21:56
    Build #6989 passed
  • Jan 18 21:50
    rprouse assigned #3734
  • Jan 18 21:50
    rprouse opened #3734
  • Jan 18 21:50

    rprouse on 3724b

    Don't install .NET Core 5.x SDK… (compare)

  • Jan 18 20:43
    mikkelbu commented #3717
  • Jan 18 20:40
    mikkelbu commented #3376
  • Jan 18 19:48
    CharliePoole commented #782
  • Jan 18 17:41
    Build #5038 passed
  • Jan 18 17:38
    SeanKilleen commented #870
  • Jan 18 17:37
    SeanKilleen synchronize #870
  • Jan 18 17:09
    NadeemBader commented #3722
  • Jan 18 17:07
    Build #5037 passed
  • Jan 18 17:03
    SeanKilleen opened #870
  • Jan 18 16:19
    Build #5036 passed
Alberto Bar-Noy
@AlbertoBN
And to answer my own question... RTFM... TestContext.Progress.
Zach Miller
@zmmille2
Hey, I'm having trouble getting VSCode to pick up Nunit tests - is there any launch.json configuration I have to do to get this to work? I was under the impression that this should "just work" with the C# extension
Zach Miller
@zmmille2
Looks like it was an issue with the solution file - .csproj files needed to be added to the .sln file, OmniSharp looks for the different .csproj files listed in the .sln file if there is one and we hadn't added it in.
Marius Morar
@marius02
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) ==========
Terje Sandstrom
@OsirisTerje
@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 :-)
Marius Morar
@marius02
is someone using https://github.com/endless-qa/nunit-test-video-recorder for recording tests?
Tanner Gooding
@tannergooding
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
Joseph Musser
@jnm2
/cc @OsirisTerje
Terje Sandstrom
@OsirisTerje
@marius02 THe issue above - are you still having it?
Terje Sandstrom
@OsirisTerje
@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.
Terje Sandstrom
@OsirisTerje
@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.
Joseph Musser
@jnm2

@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.

Eugene Krapivin
@EugeneKrapivin
Hey all! quick question, is there a way to create a generic fixture that works with TestFixtureSource as well? I'm trying to check multiple implementations of the same interface against a range of parameters and can't seem to find a way... Thanks!
2 replies
Johan Larsson
@JohanLarsson
---------- 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
Sergey Pogorelov
@SeregaFreeman
Hi everyone!
Is it possible to gather assertions as a List<Action> and then pass them to Assert.Multiple?
Mikkel Nylander Bundgaard
@mikkelbu
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();
                }
            });
        }
Terje Sandstrom
@OsirisTerje
@JohanLarsson CAn you make a repro and raise an issue?
Johan Larsson
@JohanLarsson
I'll try to narrow it down enough for a repro, just fished for hints asking here.
Terje Sandstrom
@OsirisTerje
@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 ?
Johan Larsson
@JohanLarsson
I'll have a look, hold on
Johan Larsson
@JohanLarsson
An exception occurred while invoking executor 'executor://nunit3testexecutor/': Incorrect format for TestCaseFilter Error: Missing '('. Specify the correct format and try again. Note that the incorrect format can lead to no test getting executed.
Maybe that explains it, chances are r# handles it differently
Terje Sandstrom
@OsirisTerje
Yes, they do. It is part of the FQN issues that are bothering us, still waiting for MS to come clear on this. Resharper have its own top level runner, so they handle this differently. Do you have an explicit filter there? Or, is it the test naming that goes wrong ?
Johan Larsson
@JohanLarsson
That message is pretty good, still need to find the offending test
What is fqn?
Terje Sandstrom
@OsirisTerje
Fully Qualified Names :-)
Johan Larsson
@JohanLarsson
ah
Terje Sandstrom
@OsirisTerje
Curently they have to follow C# standard, so it works for all but parametrized tests. Most of those too can be handled, but then you get some that never gets right, and special characters are one of those issues.
If you see the issues list on github, you can filter on FQN.....
Johan Larsson
@JohanLarsson
already reported in plural then
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
Terje Sandstrom
@OsirisTerje
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
Johan Larsson
@JohanLarsson
I'm pretty sure I have everything default, it is my default for everything :)
Richard Gaspar
@rgaspar
Hello everybody! I would like to ask a small help. I must have to log into a csv file when I run my unit tests, it is possible?
darrenge
@darrenge
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?
shack05
@shack05
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 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
Terje Sandstrom
@OsirisTerje
@darrenge @shack05 is correct. The namespace part comes from how the Test Explorer interprets the "fully qualified name" it receives. The testname is just the last part, which you can modify, but the FQN not.
darrenge
@darrenge
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
Terje Sandstrom
@OsirisTerje
image.png
Terje Sandstrom
@OsirisTerje
image.png
@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:
darrenge
@darrenge
Thanks @OsirisTerje ... yes, I am looking at changing the "yellow boxed" part. I like how the red boxed part works but just the overall grouping is what I want shortened. I will pursue Test Explorer folks on this one now. Thanks for your time on this.
Terje Sandstrom
@OsirisTerje
@darrenge Nice! If you get anything useful out there, please ping back with that. We're also interested in what more we can do with the Test Explorer, or simply opening up new possibilities.
Johan Eriksson
@johan-eriksson
image.png
Does anyone know a way to see which category the currently running TestFixture has?
Mikkel Nylander Bundgaard
@mikkelbu
@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